Primary and foreign keys - How to find your rows

I will be presenting a few keynotes here taken from the eBook.

Finding and defining unique identifiers for your entities is an important task. These identifiers will eventually become primary keys in your tables.

The primary key definition of one table will be propagated to related tables (underlying tables) as foreign keys in each table.

Tables may have several candidate keys: Columns that are considered to be used as primary keys.

And, you may want to define secondary keys, unique or non-unique, for performance reasons: After the system is built, you may discover bottlenecks that can be removed by adding indexes on columns that are not a part of the primary or foreign keys.

Some analysts and developers claim that the only right thing to do is to assign just a computer generated number, without any meaning, as primary keys. This is what is called surrogate, or synthetic primary keys.

Then others again tell you that you should always have natural keys, based on attributes that evolve during the analysis phase, as primary keys.

What shall one do?

• This article relates to Candidate Keys: column(s) that contain a term which may be an actual primary key for the table. Due to the length of this article, I recommend that you make a printed version of it. Read the full article on Candidate Keys
• Referential integrity is an extremely important concept in database design. But what does the term really mean? This article explores Referential Integrity

Return from Primary and Foreign Keys to Database Design Home