Professional Ruby on Rails™

Chapter 6. The Care and Feeding of Databases

One of the best features of Rails is that it protects you from many of the most irritating details of working with relational databases. For most purposes, you don't need to remember the command line syntax, unusual GUI viewer, departures from the SQL standard, or other maintenance quirks because you sit comfortably behind the shield of Rails protective abstractions.

Databases, however, are subtle and powerful, and you cannot escape their awesome might for long. There are a few situations in which a Rails developer might have to display an unusual knowledge of the details of the underlying database. One of those situations is when you are forced to use a preexisting legacy database.

Opinionated framework that it is, Rails has certain expectations about the naming and structure of database tables. It assumes, for example, that each table has a single primary key and that the name of that primary key is id. Similarly, Rails assumes that a foreign key for a relationship has a predictable name based on the table being linked to. Those conventions enable a Rails developer to consistently understand the structure of the model objects based on the database schema and vice versa.

All of which works great if you are in a position to create and maintain your own database schema. But that is often not the case. Sometimes you're brought into a project and the data already exists, and other existing projects depend on the schema, so you can't change ...