Re: Thinking about MINUS

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 07 Jan 2007 19:06:52 GMT
Message-ID: <gxboh.41808$cz.613913@ursa-nb00s0.nbnet.nb.ca>

paul c wrote:

> Bob Badour wrote:
>

>> paul c wrote:
>>
>>> Walt wrote:
>>> ...
>>>
>>>> Either NOR or NAND are enough to bootstrap to the rest of it, 
>>>> provided you
>>>> make one little extension to them:
>>>>
>>>> NOR or NAND with only one operand is NOT.
>>>>
>>>> I don't know where it leads regarding database, either.  Just a random
>>>> thought.
>>>
>>> One of a couple of reasons this topic intrigues me is that certain 
>>> scenarios aren't closed for operations in Codd's framework, eg., the 
>>> case when two operands share an attribute name that has different 
>>> types.  I realize that a whole sub-industry has been built to deal 
>>> with problems like this (based on various design disciplines, 
>>> knowingly or unknowingly, I don't know), so many people would say I'm 
>>> silly to wonder, but I can't help it.
>>
>> Wouldn't one end up with a resulting attribute defined as a union-type 
>> in a relation with no rows?

>
> Maybe, and I would be curious to see that definition work. I believe
> the conventional stance (ie., most products' stance) is that the result
> is undefined. If I have that right, my attitude is that means an
> implementation must support exceptions to handle it. Although I don't
> object to having exceptions if they give some programming or user
> safety, for some reason I can't explain, I don't like the idea of a
> system that allows undefined conditions to be produced and then must
> support exceptions to cope with them.
>
> Apart from that, when the types are the same, even the most frequent
> conventional union/"INSERT" disturbs me a little, ie., when its
> definition is based on OR or <OR> in TTM and we have a candidate key. I
> suppose that when a system supports assignment to a variable and two
> tuples in union'ed relation operands are contradictory, maybe it is
> reasonable for NEITHER to show up in the result!

Assignment is a whole different ball of wax, though, and context is very important. In one context, the user might want the dmbs to evaluate the join as I described above, and in another context the user might want the dbms to report an error (or at least a warning.)

Particularly, when the user tries to assign the resulting relation to a relvar, the dbms may not have a mechanism to properly respresent the union type to the user -- resulting in an error on assignment. Received on Sun Jan 07 2007 - 13:06:52 CST