Re: Surrogate Keys: an Implementation Issue

"Dan" <guntermann_at_verizon.net> wrote in message news:1153462870.543284.305050_at_i3g2000cwc.googlegroups.com...
>
> Roy Hann wrote:
>> "Damien" <Damien_The_Unbeliever_at_hotmail.com> wrote in message
>> news:1153366546.518700.117220_at_s13g2000cwa.googlegroups.com...
>> > 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