Re: delete cascade
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 17 Apr 2007 13:12:30 GMT
Message-ID: <2J3Vh.25372$PV3.257299_at_ursa-nb00s0.nbnet.nb.ca>
>
> ...
>
>
> 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 */
Date: Tue, 17 Apr 2007 13:12:30 GMT
Message-ID: <2J3Vh.25372$PV3.257299_at_ursa-nb00s0.nbnet.nb.ca>
paul c 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.
> -> 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? Received on Tue Apr 17 2007 - 15:12:30 CEST