Re: attribute name conflicts
From: paul c <toledobythesea_at_oohay.ac>
Date: Thu, 28 Jun 2007 15:34:06 GMT
Message-ID: <OxQgi.69635$NV3.50857_at_pd7urf2no>
>> Bob Badour wrote:
>>
>>> paul c wrote:
>>> ...
>> ...
>> Thanks, yes I did mis-type and meant it the way you put it.
>>
>> Regarding "capacity", I think I'd prefer for an app to use the three
>> different names: "volume", "weight" and "energy". My main reason
>> (psychological) would be that I find it helpful to have as much
>> transparency as possible (as one might gather from reading my frequent
>> mis-typings) but a technical reason might be that then I wouldn't need
>> to deal with "exceptions" (I presume that an expression like "A JOIN
>> B" where A and B use the "capacity" attribute name for different types
>> would, in the purest sense, be considered not well-formed, ie., it
>> would not be strictly logical to give a result such as "empty" or
>> "false" for such an expresssion.)
Date: Thu, 28 Jun 2007 15:34:06 GMT
Message-ID: <OxQgi.69635$NV3.50857_at_pd7urf2no>
Bob Badour wrote:
> paul c wrote: >
>> Bob Badour wrote:
>>
>>> paul c wrote:
>>> ...
>> ...
>> Thanks, yes I did mis-type and meant it the way you put it.
>>
>> Regarding "capacity", I think I'd prefer for an app to use the three
>> different names: "volume", "weight" and "energy". My main reason
>> (psychological) would be that I find it helpful to have as much
>> transparency as possible (as one might gather from reading my frequent
>> mis-typings) but a technical reason might be that then I wouldn't need
>> to deal with "exceptions" (I presume that an expression like "A JOIN
>> B" where A and B use the "capacity" attribute name for different types
>> would, in the purest sense, be considered not well-formed, ie., it
>> would not be strictly logical to give a result such as "empty" or
>> "false" for such an expresssion.)
> > > Whether such a join would cause an exception is a matter of applied > psychology and not theory.
1 2 1 3
This seems to give the same result as TTM's TD JOIN and I presume the same as SQL's inner or natural join.
Whereas if the header of B is {<c,t3>,<d,t2>}, with
A:
B:
I'm guessing that you might not object to this result:
<c,t1> <d,t2>
1 2
<c,t3> <d,t2>
1 3
A JOIN B:
<d,t2>
2
3
But I'm wondering if a psychological choice might also allow
(A JOIN B) = Table_Dum, or even
{A JOIN B} = Table_Dee,
as long as a dbms was consistent in its choice.