Re: Surrogate Keys: an Implementation Issue

From: Damien <Damien_The_Unbeliever_at_hotmail.com>
Date: 20 Jul 2006 05:12:05 -0700
Message-ID: <1153397525.471667.33240_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

I'll admit, I can only think up some contrived situations at the moment. It was just an idle curiosity kind of thing, And I know SQL is hardly the ideal model, but it makes this behaviour optional, so I was wondering how (if this theoretical database was to support SQL, for instance), it could be made to conform.

To be honest, until recently, I've never declared my foreign keys with "ON UPDATE CASCADE" (and when I have used it recently, I tripped over some check constraints in the second table, so the update could not be performed anyway), so it's just an area I'm interested in.

Damien Received on Thu Jul 20 2006 - 14:12:05 CEST

Original text of this message