Getting Started vs Active Record

I went through the Getting Started tutorial. I have some Ruby programming experience, but not on Rails. It was within the API context of an e-discovery program called Nuix (not Unix). In any event, I got through the tutorial and built the blog site with all the additions to forms, logging in, etc.

The next doc is for Active Record and explains a lot about how Ruby has naming conventions to translate to SQL, which I also understand. My struggle is that I liked the first tutorial doc because it was hands-on. I could follow it and test it. I have SQL Express in my environment, and this is the meat of what I want to get into. CRUD operations with a SQL DB. Is there any hands-on tutorial documentation where I can follow along and build a connection to a current db that I have or even create a new test one to connect with and build out?

I would love that kind of resource. Thank you!

You might want to try the where you build a Twitter clone. It’s been around for almost as long as Rails, and it stays up to date with the latest version and working practices. Another great tutorial (plus general helpful workflow and business and Agile tips) is the book Agile Web Development with Rails.

Either one of those will take you right up through the entire framework, and get you acquainted with how and often why Rails does things the way it does.


Thanks, will those include connecting to a SQL db? That’s what I’m really after.

Looks like I can’t get to

Do I have something wrong?

Nope, that is entirely my fault. It’s


PS: Connection to a Microsoft SQL server is not going to be documented in either of those tutorials, both of which will encourage you to use SQLite as you are learning. But to connect to a MS SQL server, you simply need to select the appropriate adapter gem when setting up your application. Rails is mostly database engine agnostic.

PPS: SQLite is a fully capable SQL RDBMS. There is very little that you cannot do with it. And it saves all of its data in a tiny file in your project folder, so you are never very far from just deleting it and running rails db:migrate again if you get frustrated.

Thanks for the fix. So when building a web app, is it recommended to just use an internal SQLite db structure and forego having a fully developed SQL schema? Part of what I love about SQL is my ability to build reusable views and stored procs. They handle 90%+ of CRUD work in reusable models. It sounds like I will have to work at building views and stored procs into rails models and controllers. Am I understanding that correctly?

Thanks again for all your replies and guidance.

When learning Rails for the first time, or even when you want to spike out an idea to see if it will work, it’s fast and easy to use SQLite. And if you want to expand on a quick throw-away demo, you can change to a different database by updating a few (maybe three) files.

That’s possible and even easy because you define your logic and relationships within the Ruby code in your project. If you build complexity into your database too early, you become dependent on the specifics of that complexity, and it becomes enormously difficult to change direction and be agile.

In contrast, if you use the framework for what it is good for, and define your database structures using migrations, then it doesn’t much matter which RDBMS you choose, or whether you change part-way through.

The time to refine your data with views and materialized views, or to move logic into stored procedures, is much later—when you are tuning the final successful application for the traffic it actually receives.

I recommend that you work all the way through the Rails Tutorial or similar, and learn more about the width and breadth of Rails before you skip around any of its conventions. They are there because they pave the 80% path for you. (Someone once likened it to building a skyscraper, but getting to start at the 30th floor.) All the busywork and time-sucking decisions take energy that is better applied to the 20% of your app that is truly unique.


1 Like

Thank you for all your advice. I definitely plan to go through everything. I just know the table structure I want to build and I can do it so fast in SQL. It would be really helpful if I could migrate a SQL table structure and even data to SQLite in a ruby site I want to develop in my sandbox.

While I am also new to Rails, I would like to throw in one aspect that in my understanding is at the core of Rails: one of its main value propositions is the use of Active Record as the ORM (object-relational manager).

This also means that one should probably start without SQL at all. Yes, my start would probably also be faster with SQL instead of Active Record, but only for a short while. So I put this initial extra effort into the "learning curve’ bucket.

Just want to echo some of this so it’s not lost in the other helpful info here:

  • Rails is designed such that it manages the schema via the “migrations” concept.
  • Rails is designed around logic existing in Ruby, not in stored procedures.
  • Rails is designed to use caching in the server and not via views.
  • Rails is designed to use SQLite when you are learning, and then a standalone DB like MySQL or Postgres for actual work and/or production deployments.

That’s not to say that you can’t import an existing schema, create and invoke stored procedures, manage views and access them easily, or use a less common database server. But what’s important is that if you are trying to both learn Rails and do things in an unconventional way, it’s going to be very difficult.

Learn Rails the way it is designed, even if you know you might want to do things differently. It’s far easier to do unconventional things with Rails when you understand its conventions - you gotta learn the rules to break the rules, so to speak.

1 Like

Guess what – you can! Just put The Brick gem into an empty Rails app, point the app at your database (this is done in the database.yml file), and then run these commands which will build out the migrations and seeds files for you:

bin/rails g brick:migrations
bin/rails g brick:seeds

You can also build out basic models and controllers if you like:

bin/rails g brick:models
bin/rails g brick:controllers

After building these out, you can either remove The Brick, or keep it there – up to you.

If you share a sample database with me then I can create a short tutorial video about what is possible with this gem.