>Hi all,
>
>I'm having a discussion with my boss and a fellow co-worker who is a dba about the usage of surrogate keys for primary keys in tables (he calls them "artificial keys").
>
>My argument is for using single-field sequence numbers as primary keys for every table and using single-field foreign keys in any child tables (which would also contain their own single-field primary keys). My reasoning is that these sequence key fields will never change because they're not part of natural data. I'm also arguing that this approach is more efficient for SQL joins, indexed seeks, etc.
>
>My colleagues on the other hand are saying that it's a mistake to use "artificial" keys because they aren't self documenting in the code. They even argue for composite keys to be used when multiple fields uniquely identify a record.
>

You are correct in using surrogate keys. What THEY are talking about
is loading intelligence into key structures - WRONG! Surrogate keys isolate
you from the data_dependency of intelligent keys and lead to better
design (read better reliability). I suspect those arguing with you have
"always done it this way and be damned if we are going to change". It is
true that debugging is easier when you can look at tables whose keys
"mean something" to a human; however, you can easily, say with VISUAL INterdev
and the "data view" run a quick "Join" or "Union" or combo and get a
results set with stored procedures.

Perhaps they should read some books on data modeling.

Good luck.

Carl R. Perkins