The Primacy of Primary Keys

I previously compared primary keys to employees who represent their companies at industry gatherings. The analogy was okay, as far as it went. But I don't want you to think of primary keys as carousing revelers at a widget-makers' convention. These are powerful, integrating forces that enable you to tightly connect tables.

In that sense, a more appropriate analogy can be found in tribal societies or even any community of extended families where blood relationships are strong. Imagine that one of the up-and-coming members of Family A marries into Family B. This young thing now has an important position in both families. As a product of Family A, he or she represents all of its interests in Family B. At the same time, he or she remains a full-fledged member of Family A.

You'll see a similar process at work in relational databases. You place a copy of the prince of Table A, its primary key, in Table B. The primary key represents all of the fields in Table A and, at the same time, is a full-fledged member of Table B. By placing copies of primary keys in the various tables of your database, you can integrate your data through relationships.

When I say "copy," I don't mean an exact replica, any more than brides and grooms assume the same role in their new families that they had in their old ones. I mean that the field will have the same data type and that the fields will contain "matching data"in other words, that they will have values that are the same data type and of the same kind.

This analogy will make more sense as you read through the many examples of primary keys presented in this chapter.