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