Re: delete cascade

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:dbCWh.114575$DE1.5577_at_pd7urf2no...
> paul c wrote:
>> Bob Badour wrote:
>>
>>> ...
>>> More and more, I am liking "on delete" or "on update" less and less. I
>>> suggest the appropriate place to handle the issue is in the view
>>> specification. If one wants "on delete cascase", one can present a view
>>> with the invoice items as an RVA.
>>> ...
>>
>> That is intriguing about RVA's. Do you have in mind entwining the notion
>> of an invoice transaction with a reference constraint by not assigning
>> the rva until it is known (by some program) that all items have been
>> inserted (into some table or other)?
>
>
> Eg., the rva has an attribute that references the invoice# in the same
> relation that has the rva as an attribute.
>

Including invoice# in the header of the rva would be redundant because for each element of the relation, every tuple in the value for the rva would have the same invoice# as the element containing the value. Since a tuple is a value, not a variable, the rva containing the items would be assigned at the same instant as the containing tuple. This eliminates the need for a referential action. The thing I don't understand is why Bob suggested using a view. If composition rather than aggregation applies, then make the rva part of a base relation. A view would add unnecessary complication to the schema, leaving room for human error. I also am mystified that he mentioned cascading updates: from what he has said in earlier posts, keys can't be updated, and if keys can't be updated, there's no need for cascading updates.

> p
Received on Sun Apr 22 2007 - 15:24:47 CEST