3.0. Introduction

Active Record provides convenient, programmatic access to the domain layer of your application. It's a persistent storage mechanism that often interacts directly with an underlying relational database. It's based on (and named after) a design pattern defined by Martin Fowler in his book, Patterns of Enterprise Application Architecture (Addison-Wesley). Fowler summarizes this pattern as:

An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.

Active Record works by creating an object relational mapping (ORM) between the Ruby objects of your application and the rows and columns of your database. This mapping allows you to interact with your database just as you would interact with any other Ruby object, eliminating the need to use SQL to manipulate your data. Instead of working with database rows, you have Ruby objects, and database columns are simply attributes of those objects that you can read or write using Ruby accessor methods.

The benefits of abstracting direct access to your database with Active Record include the ability to change the database that houses the actual data. Your application isn't "trapped" with one database forever. With the details of your model contained in Active Record, it is trivial to switch from MySQL to say, PostgreSQL or SQLite.

A domain model consists of data and a set of rules for how that data interacts with the rest of your application. Active Record allows you to define the logic of your domain model using Ruby. This gives you flexibility when defining the specific business requirements of your data, and having this logic centralized in the model makes adapting to changing requirements much easier.

Active Record, like much of Rails, relies on the concept of "convention over configuration" to simplify setup. For example, Active Record determines the fields of your database, eliminating the need to define basic accessors for each field. Active Record relies on table and field naming conventions to map your database schema into Ruby objects with a minimal amount of configuration. Table names are assumed to be the plural of the object stored in the table. So a table containing rows of employee data would be called employees. Additionally, each table (excluding link tables) is assumed to have a unique primary key called id. Foreign keys are named after the tables they reference, followed by _id. For example, a students table referencing another table named courses would contain a courses_id column. Link tables, used in many-to-many relationships, are named after the tables they link, with the table names in alphabetical order (e.g., articles_categories).

Active Record also provides dynamic attribute-based finders and a number of other helper methods that make database interaction easy and efficient.

In this chapter I'll introduce you to many of the ways that Active Record simplifies the integration between your Rails application and the database that drives it.