>So, the question i(d)s: business keys, use them or not, hide them or not. Ladies and gentlemen, I'm waiting for a wise word on the subject.

Dragan,

Business keys are part of the data. Invoices have numbers, customers have IDs, etc.. The issue of surrogate keys is this, "Do you use the customer ID as the primary key for the customer table, or do you add another field to act only as the referential integrity key?"

My arguments in favor of surrogate keys are;

1) Users never want to change a surrogate key's value because they never see it or use it for anything. This simplifies referential integrity enforcement.

2) i.e. customers, they are sometimes acquired and users like to have customer ids that are easy to remember. ACME001 may be bought by ZENITH and the users would like the customer ID to become ZENITH001. With surrogate keys this totally permissible without referential integrity overhead.

3) Often the "natural PK" for a table is comprised of multiple fields. When a PK is multiple fields the last two nromal forms come into play (4th and 5th). Those two normal forms are complex to say the least. Using a surrogate key cause all PKs to be only one field and therefore 4th and 5th NF don't apply.

4) I never have to worry about validating the uniqueness of the PK for a new record.

5) The design translates well to identity fields in C/S systems.

6) As Dr. Codd once said, "itelligent keys aren't."