Re: no names allowed, we serve types only

>> On Feb 21, 3:05 am, Jan Hidders <hidd..._at_gmail.com> wrote:
>>
>>> On 20 feb, 03:40, David BL <davi..._at_iinet.net.au> wrote:
>>> ... E.g. a relation has an attribute
>>>
>>>> containing circles and you must allow it to be addressed using either
>>>> circle or ellipse.
>>>
>>> Indeed. But the header would contain only Ellipse, and all subtypes,
>>> including Circle, would be implied. ...
>>
>> Ellipse-Circle example is unconvincing. Both are conic sections and it
>> is natural to suggest that the design would greatly benefit from
>> introducing a single class instead of many. The only objection is that
>> certain methods being constrained to subtypes (such as Circle) might
>> greatly benefit in performance.

> > What's the radius of an ellipse?> > The differences are conceptual and logical not just physical.

Must confess that I probably have a big mental block about another
aspect of type theory, eg., the very mention of it usually makes me ask
myself how to record the value of one-third of a meter (which might be
why I usually try to keep out of typing discussions). Probably my own
inadequacy, not having grown up in a metric country it never occurred to
me to wonder what one-fifth of a foot is. International agreement about
25.4 mm's being an inch doesn't help. Seems to me that the application
requirement always trumps questions of precision and any practical dbms
needs to require/allow decimal places for numeric types. While I
sympathize with Keith D's wish to eliminate the 'name,type' double, I
think that practical issues require not only so-called 'possreps' but
also what I think of as a 'name,type,use' triples. What a mess!

As for having just types, I still think that Codd introduced his
attribute names because of relations that can have two 'columns' of the
same type. I think Keith D is arguing against this and if I'm right
about that, I'd like him to deal with that case, not to say it can't be
done, just that I'd like to see whether his "copy" in a language is a
better tool.
Received on Sun Feb 21 2010 - 19:10:41 CST