General information
Category:
Databases,Tables, Views, Indexing and SQL syntax
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
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only