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