Re: no names allowed, we serve types only
Date: Fri, 19 Feb 2010 18:40:57 -0800 (PST)
Message-ID: <6555a09e-fab6-44b1-b55f-490822aaa6f5_at_z1g2000prc.googlegroups.com>
On Feb 20, 12:36 am, Kevin Kirkpatrick <kvnkrkpt..._at_gmail.com> wrote:
>
> The more I read, the more I find myself warming up to this idea.
>
> Dave, could your SUPPLIERLOCATIONCITY vs SUPPLIERDISPATCHCITY (and
> other such objections) be resolved by having two kinds of subtyping -
> one allowing implicit coersion and the other not - e.g.
>
> TYPE CITYNAME SUBTYPE STRING EXPLICIT COERSION
> TYPE SUPPLIERLOCATIONCITY SUBTYPE CITYNAME IMPLICIT COERSION
> TYPE SUPPLIERDISPATCHCITY SUBTYPE CITYNAME IMPLICIT COERSION
>
> Which might be a way of allowing various types of cities to be joined,
> while still flagging direct comparisons of SUPPLIERLOCATIONCITY to,
> say, COUNTRYNAME?
I find it strange that there can be two distinct types T1, T2, and yet implicit conversions are allowed in both directions, as if they subtype each other.
Since type systems are the source of so much controversy I would rather not add fuel!
> Admittedly, SUPPLIERDISPATCHCITY seems quite verbose for a type name -
> but perhaps that's just based on us having put up with (attribute
> name, simple type) pairings for so long.
>
> In fact, it's a bit surprising that Date wouldn't have pushed more in
> this direction himself - in his "Database in Depth (pg 24)", one
> begins to notice a distinct lack of elegance as he uses rich typing:
> PARTS = {PNO PNO, PNAME PNAME, COLOR COLOR, WEIGHT WEIGHT, CITY CHAR}
>
> (one wonders why he chose type CHAR for CITY, when CITY should only
> naturally, without explicit coersion, be comparable to other CITY
> values, not any arbitrary strings of characters)
I agree this provides some motivation, but it doesn't seem sufficient
justification to "conflate" concerns (as Bob says). The crucial point
is this: The attribute domains are part of the relation-type, whereas
the attribute names are part of the relation-value. What happens with
your suggestion?
It's very important to keep a clear separation between a value and its
declared type, in order to understand equality. Your suggestion ends
up conflating relation-type and relation-value.
How do you support sub-typing of relation-types according to subtyping
of the attribute domains, and still allow for addressing the
attributes by type name? It seems you are forced to support multiple
typenames for an attribute. E.g. a relation has an attribute
containing circles and you must allow it to be addressed using either
circle or ellipse.