Re: Surrogate Keys: an Implementation Issue
Date: 20 Jul 2006 23:21:10 -0700
Message-ID: <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. In my experience, there are some cases where a weaker dependent relationship should be restricted from changing the identity artifact in a referenced set of independent entities.
- Dan