Re: delete cascade

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:kM9Xh.118787$DE1.98245_at_pd7urf2no...
> Brian Selzer wrote:

>> "paul c" <toledobythesea_at_oohay.ac> wrote in message 
>> news:y9PWh.115941$DE1.92555_at_pd7urf2no...
>>

> As for UPDATE, it may be that I do not appreciate it fully, still not
> being able to see a fundamental place for it in the RT, let alone a formal
> definition. It may be a language or environment feature and those may
> involve dbms's, but such a connection is not by itself enough for me to
> make the transposition.

An update is an existentially quantified sentence that states how the propositions represented by the tuples in a proposed relation may be different from the propositions represented by the tuples in the current relation. Update differs from assignment in that an assignment is a sentence that simply enumerates all of the propositions represented by the tuples in a proposed relation. This difference is extremely important, because update makes it possible for the engine to enforce all transition constraints, whereas with assignment, some may need to be enforced by each application. With assignment, there's no requirement that a tuple exist in the current relation, and since keys can be updated, there's no way to verify it even if you tried, so the application that submitted the assignment must. Moreover, there may be many different algebraic expressions that can produce the same result. Given only the result, how is the engine to determine whether a delete and an insert were intended instead of an update? There's a subtle difference between an assignment consisting of a delete and an insert and an assignment consisting of an update: there's no requirement that the deleted tuples be related in any way to the inserted tuples, which is not true for update.

> p
Received on Wed Apr 25 2007 - 14:13:23 CEST