Re: more closed-world chatter

From: paul c <toledobythesea_at_oohay.ac>
Date: Sun, 06 May 2007 16:49:54 GMT
Message-ID: <SGn%h.162518$DE1.14036_at_pd7urf2no>


Jon Heggland wrote:
> Marshall wrote:
>

>>On May 5, 8:50 am, Jon Heggland <jon.heggl..._at_idi.ntnu.no> wrote:
>>
>>>>when it comes to the advantage of sub-typing in dealing with
>>>>my question.
>>>
>>>I don't know about "advantage"; I just don't see how you can avoid it.
>>
>>It's easy to avoid: just don't put subtying in the language design.

>
>
> I didn't mean how to avoid subtyping per se; I meant how to avoid it if
> you want to be able to join on attributes with different types.

Not to distract my betters on this topic, but I guess I should have originally mentioned that I think the D&D stipulation "It is required that if <A,T1> is in Hr1 and <A,T2> is in Hr2, then T1 = T2" could be gotten around simply by ensuring that no two relvars have such an attribute. This would be easy for a "catalog" to enforce.

Also, I believe Codd originally envisioned no attribute names, just domain names, ie., types and added attribute names later, in part at least, to allow for bills of materials/parts explosions.

If it is understood that all the relations in a given db obey the D&D stipulation, then I think what Marshall is musing about is a valid choice, it could be thought of as an implementation preference that doesn't deny the rest of the D&D premises. But if a dbms is aware only of attributes and not their domains/types it would still be necessary for every attribute in the db to have its operators, beyond an equality operator, if any, to be defined. Since domain or type names are likely fewer than attribute names, this would be less economical than requiring one domain/type name for each attribute.

With this view of things, maybe I didn't need to ask the question in the first place!

p Received on Sun May 06 2007 - 18:49:54 CEST

Original text of this message