Re: Thinking about MINUS
Date: Sun, 07 Jan 2007 18:54:25 GMT
Message-ID: <Blboh.561814$5R2.394456_at_pd7urf3no>
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!
p Received on Sun Jan 07 2007 - 19:54:25 CET