Re: no names allowed, we serve types only

From: David BL <davidbl_at_iinet.net.au>
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. Received on Sat Feb 20 2010 - 03:40:57 CET

Original text of this message