Re: no names allowed, we serve types only

On Feb 19, 11:36 am, Kevin Kirkpatrick <kvnkrkpt..._at_gmail.com> wrote:
> On Feb 18, 9:44 pm, David BL <davi..._at_iinet.net.au> wrote:
> > On Feb 15, 3:01 pm, Keith H Duggar <dug..._at_alum.mit.edu> wrote:
>
> > > Of course if you are dealing with crippled domain support then names
> > > are essential. But envision a system with rich type support. I'm
> > > asking
> > > if, in that world, we even need to bother with attribute names at all?
>
> > I think a rich type system is desirable. I suggest there should be as
> > many types as necessary according to exactly where it is considered
> > useful to test for equality. No more and no less.

[snip David's excellent exposition]

Thanks David for putting meat on the bones! Indeed this is exactly the direction I was thinking of. I'd never run into the "Universal Relation" idea and need to look into that. Do you happen to have any of the better references you found handy?

> > I also think specialisations of STRING are quite useful, and happily
> > the problem is much simpler. E.g. we could define strict subtypes of
> > STRING such as CITYNAME and SUPPLIERNAME. This assumes we aren't
> > interested in cases where a supplier's name happens to match a city's
> > name. i.e. we aren't using the database to answer trivia questions!
> ...
> > Ok, now back to the subject of the thread. Despite using a rich set
> > of types I believe it is still necessary to use attribute names which
> > serve as role names. For example consider the external predicate
>
> > Supplier S is located in city L and dispatches products to city D.
>
> > Consider furthermore that in that application it's considered useful
> > to join on L=D. In that case the attribute names L and D need to have
> > the same type (e.g. CITYNAME).
>
> > Introducing (alias) types named SUPPLIERLOCATIONCITY and
> > SUPPLIERDISPATCHCITY doesn't seem a good idea to me. I like to think
> > of these as roles not types.
>
> 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?

Yes precisely. A rich type system can provide conveniences such as that. In addition, though the equality operator is the primary concern above, a type system can provide fine grained control of explicit/implicit coersion by allowing one to add and remove individual function signatures from the explicit/implicit set.

We can also use inline explicit casts just as one would might use rename in a join for attribute names. So for the L=D above in they are declared as explicit coersion then one could write CITYNAME(L)=CITYNAME(D) which is very similar to some of Date's casting examples here and there.

> 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.

Right, it's probably not any more verbose than the pair taken as whole.

> 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)

It's funny you mention that example as it is precisely one of the examples (along with other examples in Date's books) that started to give me a nagging feeling there was some redundancy to be simplified in the classical (name, type) attribute pair.

> Anyway, very intriguing idea Keith.

Thanks! I'm happy it's spawning some lively discussion here at least. Personally I'm still trying to digest David's points re a typeless system. I think there is some insight to be gained from it but I still haven't had the time to finish the meal ;-)

KHD Received on Fri Feb 19 2010 - 22:30:07 CET