Mike:

> I think the reason their not used is so that there is something the developer
> uses to relate tables that the User has no oppuritunity to mess with.

Not 100% true. The user can always mess around with the key value using a data
mining tool, be it surrogate or natural. Furthermore, an application can be designed to prevent changes to any field, including PK fields once saved.


> Otherwise, if the user changes the primary key (for example the Part_ID)
> you have to scan through every table where the old Part_ID and make the
> change there.

I use both surrogate and natural keys and I usually write the cascade update
for all tables. I don't like the idea of having frequent cascade updates
occuring in production and that's one of the reasons why I lean towards
surrogate keys whenever it is not obvious that one "almost static" field can
serve as PK.


> What a pain.

Agreed, but it is necessary.


> Now if the tables are normalized, and you change the Part_ID, the surrofate
> PK is still good everywhere in teh system

Yes but if they change the PK value with a data mining tool and you don't have
a cascade update, you're in the deep end...

I don't care if a key value changes from _time to time_ because it is handled
by my cascade update. What I don't want is having frequent key value changes because of contention issues.


Daniel