Re: relationship in the database

>I think Costin is right when he says that the ON UPDATE CASCADE can
>sometimes be very useful.

Yes, agreed, but there is an underlying concept here that is much more powerful.
However I think it might be an idea to start a new thread to explore it...

>However, I think the concept is consistent with relational asignment. For
>example, ON UPDATE CASCADE becomes a trigger that checks if after the
>assignment a certain candidate key value has disappeard and a new one has
>been added.

>If so then it performs an assignment to the referring relation
>that replaces the tuples that refer to the old cand. key value with
tuples
>that refer to the new cand. key value.

But exactly how do we know _which_ new tuples correspond to which old tuples?

T1(_A_, B)
T2(_A_, C) REFRENCES T1(A) ON UPDATE CASCADE ON DELETE CASCADE INSERT INTO T1 {(1,5),(2,6)}, INSERT INTO T2 ({1,8), (2,9)} T1 := {(3,7), (4,5)} 5),(2,6)

now what happens to T2? did tuple (1,5) become (3,7) or did it become (4,5) or neither?
  Should T2 now look like {(3,8), (4,9)} or {(4,8), (3,9)} or neither?

The RM cannot say.

And it cannot say because UPDATE/INSERT/DELETE/UPSERT/UPDELSERT/.. are NOT core concepts of the relational model, and so neither can ON UPDATE CASCADE be part of that core.

ON UPDATE CASCADE needs to be built _on top_ of the relational model, assuming you happen to think it is a good idea as currently stated.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Tue Sep 17 2002 - 19:20:01 CEST