Re: attribute name conflicts
From: paul c <toledobythesea_at_oohay.ac>
Date: Thu, 28 Jun 2007 17:54:23 GMT
Message-ID: <jBSgi.70173$xq1.39854_at_pd7urf1no>
>> 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.
>>
>>
>>
>> That intrigues me. Does that mean that you wouldn't object to the
>> following interpretation of join?
>>
>> First, assume the header of relation A is {<c,t1>,<d,t2>} and that of
>> relation B is the same.
>>
>> A:
>> <c,t1> <d,t2>
>> 1 2
>>
>> B:
>> <c,t1> <d,t2>
>> 1 3
>>
>> A JOIN B:
>> <c,t1> <d,t2>
>> 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:
>> <c,t1> <d,t2>
>> 1 2
>>
>> B:
>> <c,t3> <d,t2>
>> 1 3
>>
>> I'm guessing that you might not object to this result:
>>
>> 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.
Date: Thu, 28 Jun 2007 17:54:23 GMT
Message-ID: <jBSgi.70173$xq1.39854_at_pd7urf1no>
Bob Badour wrote:
> paul c wrote: >
>> 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.
>>
>>
>>
>> That intrigues me. Does that mean that you wouldn't object to the
>> following interpretation of join?
>>
>> First, assume the header of relation A is {<c,t1>,<d,t2>} and that of
>> relation B is the same.
>>
>> A:
>> <c,t1> <d,t2>
>> 1 2
>>
>> B:
>> <c,t1> <d,t2>
>> 1 3
>>
>> A JOIN B:
>> <c,t1> <d,t2>
>> 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.
> > > Actually, while the header of the result is correct, the body is > incorrect. The body above should be empty because B does not contain any > rows where d=2 and A does not contain any rows where d=3. > >
>> Whereas if the header of B is {<c,t3>,<d,t2>}, with
>>
>> A:
>> <c,t1> <d,t2>
>> 1 2
>>
>> B:
>> <c,t3> <d,t2>
>> 1 3
>>
>> I'm guessing that you might not object to this result:
>>
>> A JOIN B:
>> <d,t2>
>> 2
>> 3
> > > I would object. The header of the result must have a 'c' attribute whose > type is the most specific supertype of t1 and t3. Once again, the body > would be empty. > >
>> 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.
> > > Psychology cannot alter the correct header. Psychology can only choose > between throwing an exception or returning an empty body with the > correct header.
Thanks again. I think I'm with you, especially on the last comment. (Before I saw this I sent another post admitting in advance that my question might have seemed insolent.)
p Received on Thu Jun 28 2007 - 19:54:23 CEST