On May 30, 2007, at 11:51 , Gregory Stark wrote:
Firstly trying to update such a key you'll immediately bump into
the practical
reasons why it doesn't work well. You have to update every record
everywhere
in the database that references that key which represents a lot of
potential
work.
As I mentioned earlier, if you plan on updating keys, you'd have ON
UPDATE CASCADE set, so there shouldn't be any work here. There may be
performance issues as those changes propagate, however.
But secondly, what happens to applications that have read that
value into
their local state and then try to operate on it? When they return
to perform a
second operation and use the primary key to specify the record they
wish to
operate on they'll find it gone.
This is an interesting point. What this boils down to is having a
method of cascade the key changes outside of the database. Depending
on how long the data is cached and how gracefully the application
deals with errors when the lookup value is no longer present. In a
case where you know primary keys are going to be updating, you'd
probably want some additional key attribute that *is* stable for use
outside of the database. Anyway, thanks for the food for thought!
Michael Glaesemann
grzm seespotcode net
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
