>Jeff,
>
>>Are there any books/articles/papers I could find preferrably written by known experts in the field that could back up my argument for using surrogate keys?
>
>Start with a search of your MSDN Library. I tried with "surrogate primary key" and got several listings, which I have excepted here:
>
>Best Practices Data Handling Issues
>Doug Hennig
>
>There are two kinds of primary keys for a table: user-defined and system-defined (also known as “surrogate”). I prefer surrogate keys that the user never sees because they avoid all kinds of complications like cascading primary key changes (because the primary key never changes, there’s no need to cascade it), especially using the current Referential Integrity Builder, which doesn’t properly handle compound primary keys.
>
>Turn Your VFP App Client/Server: A 12-Step Program, Part 2
>Jim Falino
>
>The argument for surrogate keys
>If you do have multiple fields that make up your primary keys, I suggest using a system-generated surrogate key in addition. Having this field, typically an integer type, will give you the luxury of a unique Row ID that you'll be glad you have. Along with this, for child tables you'll want to add one more integer field to serve as the foreign key. You'd populate it with its parent's surrogate primary key before saving a new child.
>
>The benefits of surrogate keys include faster joins, faster updates, faster deletes, and the simplified retrieval of the children of a parent. The only drawback is generating them. I use a system table of next numbers -- it contains one row per table in the application -- but this can cause multi-user contention problems if you're not careful. Since these keys really are meaningless (that's why they're also called abstract keys), you shouldn't attempt to get the next sequential number from the server while in the midst of a transaction. This might create too much contention on the system table when you need primary keys for a highly active table. It's better to get the key outside of the transaction and risk losing it if an update fails.
>
>To Sequence or Not To Sequence
>Vic Bachulis
>
>In this article, Vic explores the art of selecting keys and offers surrogate keys as an alternative to traditional column-based keys.
>
>As it was once so eloquently stated by SQL guru Chris Date, a key value should represent "the key, the whole key, and nothing but the key." As a database designer, you're confronted with a million little details that can ultimately seriously affect your system's (or your client's) performance and functionality at every turn. Nowhere is this more apparent than in the design of your table keys. Relational databases are wholly predicated on the concept of keys and key values, but how can you best implement them in your own database design?

Thanks abunch, David!