|
![](/i/fill.gif) |
Invisible wrote:
> The point is *totally* to have a PK that never changes, since changing a
> PK is a tricky business which you want to avoid. (Duplicate PKs would of
> course be much, much worse, but that's fairly easy to avoid.)
Actually, I think this is backwards. The trick would be to pick a PK that
never changes because it actually uniquely identifies the entity the record
represents (which, as I have said, is not always possible). The problem is
not to avoid duplicate PKs, but to avoid two records with different PKs
representing the same thing. If you already have a "unique index" on a table
for fields you don't anticipate changing, that can easily serve as the PK
for that table without having yet another arbitrary identifier.
By giving each record a PK of some random number, you have eliminated the
ability to distinguish duplicates. Actually updating a PK on a record, while
possibly time-consuming, shouldn't be problematic from a theoretical point
of view. That's precisely what foreign keys, cascading updates, and
cascading deletes are for.
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
![](/i/fill.gif) |