Re: delete cascade

From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 18 Apr 2007 02:22:56 GMT
Message-ID: <4ifVh.89132$DE1.62844@pd7urf2no>

David BL wrote:
> On Apr 18, 9:31 am, paul c <toledobythe..._at_oohay.ac> wrote:
>

>>Bob Badour wrote:
>>
>>>...
>>>I am still lost. When does it delete? When does it not delete?
>>
>>Oh, I was assuming a delete is not possible if it would cause the
>>constraint to be violated.  Just what would happen would depend on
>>implementation, personally I'd prefer a result of "false" but I guess
>>many people prefer exceptions, just as many prefer "delete cascade".
>>
>>p

>
>
> That's not consistent with your OP where you say
>
> ...Ie., why shouldn't delete always mean so-called "cascade"?
>
> It seems to me there is only one logical constraint
>
> item exists => inv exists
> ...

As I saw it, Bob introduced another constraint, which I could call "NOT CASCADES" and I tried to form it in an unconventional way with <AND> and <OR> TTM equivalents, in other words in my view given Bob's constraint, both relations have constraints.

> This must be met on any snapshot of the DB.
>
> For this one logical constraint there are two possible "procedural"
> constraints when deleting an invoice:
>
> delete cascade : delete invoice -> delete items
>
> no delete cascade : item exists -> don't delete invoice
>
> You can express the logical constraint in any way you like, but in the
> end they are all equivalent. I don't see how it has any bearing on a
> procedural constraint.

I don't know what the procedural constraint is. I was trying to avoid procedure.

p Received on Tue Apr 17 2007 - 21:22:56 CDT