This is the final article in my Introduction to Rails series. You can find the first piece here.

If you’re used to working with PHP and MySQL, as I was, then you’re probably familiar with accessing the database via the Structured Query Language (SQL). Since the database speaks this language it is the natural way to communicate. While Rails gives you the ability to execute arbitrary SQL the majority of your database interaction is intended to be through the object-relational mapping provided by ActiveRecord.

Object-Relational Mapping

ORM software is responsible for making interactions with the database “feel” more or less like interactions with your application models. The most simple example is taking an object in memory and calling a save method on it which will execute the proper SQL statement required to update or insert any values which have been changed into the database.

Most of the time your application will need to load information from the database into models in memory. This is also handled by the ORM library. By specifying a combination of model type and optionally ID, created_at, updated_at or any of your custom model variables you can instruct the ORM software to request the matching data from your storage system.

What makes this special? There’s nothing spectacularly mind-blowing about it. It’s pretty straightforward, simple software. Given that, why should we use it? Turns out, it saves a lot of typing, which saves time. It also cuts down on the potential bugs that inevitably pop up by providing a far more limited interface than the vast realm of unchecked SQL. The natural implication of this change is that advanced queries are not as easy to do via an ORM as they are with pure SQL. In those situations you’ll want to bypass the ORM.

ActiveRecord

Rails provides developers with an ORM library called ActiveRecord. It is by far the most widely used, but not the only, Rails ORM. Due to the modular nature of Rails one may choose to substitute other software such as DataMapper. I’ve heard good things about DataMapper but I haven’t had the chance to use it yet so I can’t speak from experience there.

ActiveRecord, on the other hand, I’ve used extensively. Thus far it has met all of my needs with only a few situations where I judged it to be more difficult than the equivalent SQL. That said, I think it’s important for anyone who is just starting out to learn how to write proper SQL and how the underlying databases respond. As of Rails 3.2 ActiveRecord helps you with this process by giving you access to the generated SQL queries using the explain command. You can also watch your development console (where you launched rails server) to see the queries being executed live.

The End?

This concludes my “Introduction to Rails” series, which actually turned out to be a misnomer. It’s more of a “Why I Choose Rails Over PHP” series, or perhaps “The Niceties of Rails Compared with PHP.” I’m hoping that people will overlook my mistake and that the series content helps give a few people that extra incentive they need to start learning Ruby on Rails.

If you’re interested in reading more about web development (and sometimes server administration), I publish a new blog post every Monday. My next article will be a tutorial on using AngularJS with Ruby on Rails [Update: It’s posted here].

Have any questions? What about suggestions, problems, or complaints? You can direct them all to tarential@tarential.com. I’m still new at blogging and this site uses all custom software [Update: Not anymore! Now it uses Jekyll]. I’m sure I’ve made mistakes which are apparent to you but not to me. I’d appreciate if you let me know when you see them :)