Question

I would like to see an example of:

• When this is appropriate
• When this is not appropriate

Is there a time when the choice of database would make a difference to the above examples?

Answer 1

This really seems to be a question about surrogate keys, which are always either an auto-incrementing number or GUID and hence a single column, vs. natural keys, which often require multiple pieces of information in order to be truly unique. If you are able to have a natural key that is only one column, then the point is obviously moot anyway.

Some people will insist on only using one or the other. Spend sufficient time working with production databases and you’ll learn that there is no context-independent best practice.

Some of these answers use SQL Server terminology but the concepts are generally applicable to all DBMS products:

---

Reasons to use single-column surrogate keys:

• Clustered indexes. A clustered index always performs best when the database can merely append to it – otherwise, the DB has to do page splits. Note that this only applies if the key is sequential, i.e. either an auto-increment sequence or a sequential GUID. Arbitrary GUIDs will probably be much worse for performance.

• Relationships. If your key is 3, 4, 5 columns long, including character types and other non-compact data, you end up wasting enormous amounts of space and subsequently reduce performance if you have to create foreign key relationships to this key in 20 other tables.

• Uniqueness. Sometimes you don’t have a true natural key. Maybe your table is some sort of log, and it’s possible for you to get two of the same event at the same time. Or maybe your real key is something like a materialized path that can only be determined after the row is already inserted. Either way, you always want your clustered index and/or primary key to be unique, so if you have no other truly unique information, you have no choice but to employ a surrogate key.

• Compatibility. Most people will never have to deal with this, but if the natural key contains something like a hierarchyid, it’s possible that some systems can’t even read it. In this case, again you must create a simple auto-generated surrogate key for use by these applications. Even if you don’t have any “weird” data in the natural key, some DB libraries have a lot of trouble dealing with multi-column primary keys, although this problem is quickly going away.

Reasons to use multi-column natural keys

• Storage. Many people who work with databases never work with large enough ones to have to care about this factor. But when a table has billions or trillions of rows, you are going to want to keep the absolute minimum amount of data in this table that you possibly can.

• Replication. Yes, you can use a GUID, or a sequential GUID. But GUIDs have their own trade-offs, and if you can’t or don’t want to use a GUID for some reason, a multi-column natural key is a much better choice for replication scenarios because it is intrinsically globally unique – that is, you don’t need a special algorithm to make it unique, it’s unique by definition. This makes it very easy to reason about distributed architectures.

• Insert/Update Performance. Surrogate keys aren’t free. If you have a set of columns that are unique and frequently queried on, and you therefore need to create a covering index on these columns; the index ends up being almost as large as the table, which wastes space and requires that a second index be updated every time you make any modifications. If it is ever possible for you to have only one index (the clustered index) on a table, you should do it!

---

That’s what comes to mind right off the bat. I’ll update if I suddenly remember anything else.