Mike,
I know that you know this but your message was convenient.
The rationale for surrogate keys is really very simple logic. It doesn't necessarily address all of the issues but it doesn't have to because it is a compelling logical argument.
The role of primary key is absolutely critical for a relational database design to work at all.
The role of a primary key is very restricted. This is saying that the primary key, unlike other attirbutes of an entity, has a number of severe restrictions on what can happen to it and what has to happen elsewhere when the primary key is affected that are totally unrealted to actual value the attribute holds.
A surrogate primary key has no other meaning or domain constraint outside its responsibility as the primary key. Therefore it has no other intervening influences on its value outside of being the unique identifier and relational "glue".
A natural primary key, as defined as being an attribute that carries descriptive information about the entity, has other influences on its value that are outside its role as primary key. It has domain constraints that are not directly related to its role as primary key.
So, if I have to decide which way to go, it is simple for me. I have two choices, one is pure and has no complicating factors involved, the other has complicating factors involved. I will always choose the simple approach.
I put no value in the statement that using surrogates causes there to be more joins in the system. Normalization creates a data design that is as free of delete and update anomalies as is possible. Using surrogate keys has no influence on what is a normalized design.
As a matter of fact, using surrogate keys (which are always one attribute) limits the normalization process to the Boyce-Codd NF because the last two NFs relate only to PKs that have more than one component attribute. Using natural keys will eventually cause a PK to be complex and require the application of both 4th and 5th NF to the design. It is easier to use surrogate keys.
