Re: more on delete from join

From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 26 Aug 2009 02:47:48 GMT
Message-ID: <on1lm.40697$Db2.22781_at_edtnps83>


Bob Badour wrote:
> paul c wrote:
>
>> Mr. Scott wrote:
>>
...

>>> I don't think this is right.  It assumes that a delete from J 
>>> translates into a delete from both A and B, when a delete from either 
>>> A or B would suffice.  ...
>> Yes, it does make that assumption, consequence of logical independence 
>> I think.

>
> Preservation of symmetry as well. However, I see no theory to support
> either choice, which is why I prefer the pragmatism of allowing an
> expert user to specify how the delete should operate in this situation.

No argument that people who design the predicates in the first place should be able to trump any dbms conventions they want to, although I doubt if more than a few at most of today's dbms'es can express constraints flexibly enough to always allow that. Maybe I'm talking about a convention rather than theory, but my basic point seems logical to me and might go like this: While a relation represents the extension of a predicate, there is no way for a dbms designer (as opposed to a db designer) to choose whether a particular relation value formed by <OR> or UNION has a predicate that involves disjunction, at least in the absence of explicit constraints to prevent or void results that are not wanted. Since all propositions represented by the tuples of a relation (at least tuples in named relations) are taken to be true as far as that relation is concerned (maybe false in the face of other relations, but if false, they're not individually false, rather their logical conjunction is false), the fact that a named relation might have been formed by means of disjunction isn't of any consistent use to a mechanical engine. Most base relations are formed with disjunction and I don't see why views should be treated differently. In the absence of contrary constraints, it seems most reasonable to me for a dbms, say within the scope of a named view, to 'assume' identical predicates for relations with equal headers.

My view of RT is extremely narrow, partly to avoid mysticism and partly to see the minimum machinery a dbms really needs. I think a relation's 'definition' consists of nothing more than a header and constraints and the constraints must all be expressible in the chosen algebra (this doesn't mean I think the dbms needs to directly execute the algebra). Received on Wed Aug 26 2009 - 04:47:48 CEST

Original text of this message