So far we have improved our data model and Rails model layer substantially from the small set of tables we began with. Specifically, we have:
Added constraints everywhere
Enforced referential integrity
Added basic indexes
Factored out repeated data model chunks with database inheritance, and created an analogous Rails plugin to facilitate reuse
Factored out columns that were teetering on the edge of violating third normal form into fully fledged tables
Created domain tables for our domain data, and analogous Rails models and constants
We have done quite a bit, but our data model is still not enterprise solid. In this chapter, we will discuss two related topics that can help us get closer to our goal. The first is the idea of keys made up of multiple columns, otherwise known as composite keys. The second is a topic that proverbial wars have been fought over, which boils down to whether primary keys should be simple id columns, as is the Rails default, or the more complex composite or natural keys, which rely on unique identifying information in the records themselves.
In Rails, as it comes out of the box, the decision to use id columns has been made for you. However, composite keys have inherent benefits over simple id keys. In reality, both conventions have pluses and minuses. In this chapter, we’ll learn the pros and cons of each convention. We’ll learn how to make composite keys work in Rails through use of a plugin. Then, we’ll have ...