Re: By The Dawn's Normal Light
Date: Wed, 3 Nov 2004 12:11:00 -0600
Message-ID: <cmb707$g14$1_at_news.netins.net>
"erk" <eric.kaun_at_pnc.com> wrote in message
news:1099430678.404757.60290_at_z14g2000cwz.googlegroups.com...
> > The trouble comes when a relation can have an attribute whose domain
> is a
> > relation. Now there's an incestuous relationship between the
> relational
> > engine and the type engine. The type engine has to know about
> relations,
> > in order to be a type engine. The relational engine has to know
> about
> > relations in order to be a relational engine. But do they each know
> that
> > the other one also knows?
>
> I don't think it's a problem in practice. A database consists of
> relation-typed variables, and could certainly delegate the handling of
> that type to the type engine, which would know about others. In fact,
> even in relational expressions, user-defined type-specific operators
> can be used, so the relational engine is going to do that anyway.
>
> Hmmm... I'm starting to wonder what is in the relational engine then,
> if relations as types are handled by the type engine. Constraints are
> over sets of relvars, so they're outside the confines of the type
> engine... or are they?
I don't know why they need to be. From my perspective a relation is simply a type, as is a function, a set, a bag, a list, ...
> I'm a little tired now to think about this, so perhaps someone can
> chime in. But certainly relation-valued attributes can have
> constraints, and so there's a recursive relationship.
makese sense to me, but I've heard I'm a bit of a "kook" :-)
> Is the relation just a special type? It certainly allows more
> flexibility than most "type generators" (like List or even Set, which
> have various accessors but are parameterized primarily by the type of
> the element they can include).
It is one type, just as a function is a type, or a vector, or list, or bag, or ... One could define a schema or a namespace as a set of relations, so there's another type. It does make some sense to focus on a set of very useful types and then make the system extensible to other types as desired, but I see nothing intrinsic in "relation" that makes it a candidate for being the only type that includes multiple "atomic" values. Cheers! --dawn Received on Wed Nov 03 2004 - 19:11:00 CET