Working with a Database: Active Record

To be sure, you don’t need Active Record (or any ORM) to talk to and manipulate your database. In fact, databases have their own language called Structured Query Language, popularly referred to as SQL, which is supported by nearly every database in existence. Using SQL, you can view column information, fetch a particular row or a set of rows, and search for rows containing certain criteria. You also use SQL to create, drop, and modify tables and insert, update, and destroy the information stored in those tables. The problem with SQL is that it’s not object-oriented.

Object-oriented programming and relational databases are fundamentally different paradigms. The relational paradigm deals with relations and is mathematical by nature. The object-oriented paradigm, however, deals with objects, their attributes, and their associations to each other. As soon as you want to make objects persistent using a relational database, you will notice something: there is a rift between these two paradigms—the so-called object-relational gap. An ORM library like Active Record helps you bridge that gap.

Note  Active Record is based on a design pattern. Design patterns are standard solutions to common problems in software design. Well, it turns out that when working in an object-oriented environment, the problem of how to effectively communicate with a database (which is not object-oriented) is quite common. Therefore, many smart people have wrapped their heads around the problem of how best to bring the object-oriented paradigm together with the relational database. One of those smart people is Martin Fowler, who in his book, Patterns of Enterprise Application Architecture (Addison-Wesley, 2002), first described a pattern that he called an Active Record. In the pattern Fowler described, there is a one-to-one mapping between a database record and the object that represents it. When Rails creator David Heinemeier Hansson sought to implement an ORM for his framework, he based it on Fowler’s pattern.

Active Record lets you model real-world things in your code. Rails calls these real-world things models—the M in MVC. A model might be namedPerson,Product, orEvent, and would have a corresponding table in the database:people,products, orevents. Each model is implemented as a Ruby class and is stored in theapp/modelsdirectory. Active Record provides the link between these classes and your tables, allowing you to work with what look like regular objects, which, in turn, can be persisted to the database. This frees you from having to write low-level SQL to talk to the database. Instead, you work with your data as if it were an object, and Active Record does all the translation into SQL behind the scenes. This means that in Rails, you get to stick with one language: Ruby.

Note  Just because we’re using Active Record to abstract our SQL generation doesn’t mean that SQL is evil. In fact, Active Record makes it possible to execute SQL directly whenever that’s necessary. The truth is that raw SQL is the native language of databases and there are some (albeit rare) cases when an ORM simply won’t cut it.