Enterprise Rails

Chapter 8. Composite Keys and Domain Key/Normal Form

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 ...