Re: Surrogate Keys: an Implementation Issue

From: Roy Hann <specially_at_processed.almost.meat>
Date: Fri, 21 Jul 2006 09:31:12 +0100
Message-ID: <>

"Dan" <> wrote in message
> Roy Hann wrote:
>> "Damien" <> wrote in message
>> > Just a quick question. What if, for whatever reason, you did NOT want
>> > "ON UPDATE CASCADE" semantics? It seems you cannot avoid them in your
>> > situation...
>> Before exerting myself to think of an answer to this, why, after assering
>> that an attribute is a foreign key, would it ever be reasonable not to
>> want
>> ON UPDATE CASCADE? If the attribute is not a foreign key, don't say it
>> is.
>> Roy
> Why wouldn't it be a foreign key with ON UPDATE RESTRICT semantics?
> If I had a wife who was a person with a personal name and personal
> information that was listed in a MARRIED TO relation and further
> constrained to being referenced from a PERSON relation, I wouldn't want
> my new wife to supplant my ex-wife's name, but keep her personal
> information when I changed the name in the MARRIED TO relation and had
> it propagate back to the PERSON table.

I am really struggling to think how your MARRIED TO table is designed if ON UPDATE CASCADE is a problem for it. What are its attributes? What is its predicate?

Roy Received on Fri Jul 21 2006 - 10:31:12 CEST

Original text of this message