Re: delete cascade

From: paul c <toledobythesea_at_oohay.ac>
Date: Tue, 17 Apr 2007 13:21:42 GMT
Message-ID: <GR3Vh.87974$aG1.10937@pd7urf3no>

Bob Badour wrote:
> paul c wrote:
>

>> Bob Badour wrote:
>>
>>> paul c wrote:
>>
>>
>> ...
>>
>>>> Sorry, I think I put that wrongly.  Maybe the constraint that "one 
>>>> may not delete an invoice when any items exists would look something 
>>>> like "(NOT Invoices{Invoice#}) AND Items{Invoice#} = FALSE", ie., a 
>>>> reference from the complement of invoices to items.
>>>
>>>
>>> I am not sure I fully understand your syntax and the order of 
>>> precedence you are using, but wouldn't demorgan make that:
>>>
>>> Invoices{Invoice#} OR Items{Invoice#}
>>>
>>> That doesn't seem like the constraint at all to me.
>>
>>
>> Not sure I entirely understand my notation either but here's what I 
>> get if I substitute "A" for the invoices projection and "B" for the 
>> items projection:
>>
>> (not A) and B = false               /* ie., the join is empty */
>>
>> -> not ((not A) and B) = true       /* negate both sides */

>
>
> Ahhh, so 'and' and 'or' have higher precedence than '='. That explains
> much.
> ...

Sorry for not explaining that.

>

>> -> A or (not B) = true              /* de Morgan */
>>
>> in other words,
>> Invoices{Invoice#} OR NOT(Items{Invoice#}) is not empty.

>
>
> Okay, that makes sense. How does it relate to cascading again?

Well, if I try to delete invoice 99 while there are items for that invoice the result of the "OR" would not include invoice 99 and so would be empty as far as invoice 99 is concerned and so would not satisfy the constraint. (I realize I'm using a generalized form of "OR" here which is why I might prefer to express the constraint using "AND".)

p Received on Tue Apr 17 2007 - 08:21:42 CDT