Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: delete cascade

Re: delete cascade

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 17 Apr 2007 14:50:04 GMT
Message-ID: <w85Vh.25400$PV3.257705@ursa-nb00s0.nbnet.nb.ca>


paul c wrote:

> Bob Badour wrote:
> 

>> 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?
> 
> It would prevent the deletion of invoice 99 and thus any cascade unless 
> there were no items for invoice 99.  (assuming a system that always 
> cascades deletions, ie., one that has no "cascade" keyword.)

If it prevents deletion, it doesn't "always cascade deletes". I really don't have a clue what you are trying to say. It doesn't make any sense to me whatsoever. Received on Tue Apr 17 2007 - 09:50:04 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US