Joe,

>>a) never use a PK which has "business meaning"; use a generated PK;
>>b) never ever let your end users touch the PK of any table.

JM> I've heard this a lot here, but I don't think I've ever heard an
JM> explanation of why. If you can guarantee uniqueness of the PK, and use ON
JM> UPDATE CASCADE, then why not let it have "business meaning"?

one simple reason is that business meaning tends to change as time
passes. This can mean that datatypes may change to follow the business
rules; and changing the datatype of a couple hundred primary and
foreign keys in a huge database is as close as a Royal PITA as
anything can be, to me.

Even if datatypes don't change (but you never know, so you don't sleep
at night :-)), the cost of applying a cascade update on that huge
database is, err... huge. Even more so considering the MG Architecture of
InterBase/Firebird.

I could go on, but I think you get the point.
Ciao
--
Nando mailto:nandod@...