Re: delete cascade

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 17 Apr 2007 13:25:23 GMT
Message-ID: <7V3Vh.25374$PV3.257551@ursa-nb00s0.nbnet.nb.ca>

paul c wrote:

> 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".)

I understand how it expresses the constraint. What does that have to do with cascading, though? Received on Tue Apr 17 2007 - 08:25:23 CDT