Re: By The Dawn's Normal Light

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Wed, 27 Oct 2004 14:41:38 -0500
Message-ID: <clotm2$oaq$>

"erk" <> wrote in message
> > Good to "see" you again, erk.
> Likewise, thanks.
> > Maybe part of my question is why we have relations and then all other
> types.
> > Why are relations not simply one of the types? I suspect this is in
> order
> > to keep it simple, but I don't see that it does.
> >
> > Once relation is a valid
> > type within a relation (as it is by newer defs) then a relation is a
> type
> > like a list or set or bag or ... I'm pretty sure that I'm simply
> ignorant on
> > this and that the complexity that would have to be added would be
> "too much"
> > but the separation of the relational and type engines doesn't appear
> to buy
> > anything for the user -- does it?
> Very good question, and a topic worth exploring. I'm tired, so here are
> rambling thoughts and opinions intermixed:
> - a DBMS needs to have some structure that it understands
> - relations (like lists and sets) are "type generators" - they're
> containers, but relations say much more about the contents than lists
> and sets
> - relations are more useful containers than lists and sets and files,
> I'd argue, for these reasons:
> - relations allow integrity constraints, which are extremely useful and
> communicative
> - relations give enough visibility into their contents' (tuples')
> structure to allow powerful operators beyond what lists and sets offer
> - types allow a virtual extension of the database and its operations

and relations that are functions (have a primary key) seem to be even more useful to me, but I have just as much proof of that as there is that relations are a good top level structure.

> A DBMS could possibly handle multiple types of containers, but that
> would be confusing, I think, and add complexity that shouldn't be if
> you can avoid it.

We want to minimize the complexity for the user even if it means the tools need to be more complex.

> > I agree that the database need not know more about a List or Set than
> about
> > a Date, but why does it need to know more about a Relation than about
> a
> > List?
> I'd say that for any DBMS, there should be a minimal number of
> "primary" structures -

by def of "primary" - I agree. I'm not sure that the primary vs everything else approach with structures is that useful. I agree there are lots of issues with Java, as with any language I've ever used, but I prefer having Object as the most abstract structure and then we can define any type of collection we need. We need not be married to the relation. There is then difficulty in querying the data at this point, but we can address that too. I'd suggest Haskell instead, but there is no reason to believe it will have any of the impact that Java has had (and many reasons to believe it will not).

> simplify as much as possible without
> oversimplifying.

This is one of those statements that I think got the relational theorists in trouble We don't really want to simplify the mathematics of language in order to make language more useful. In fact, if we have a language that is very useful, the mathematics of it is likely very complex. We want it to be simple for the user to do what they need to do, not for the database engine.

> At the same time, user extensibility is critical.
> Consistent and well-defined, high-level operators are powerful -
> high-level because they operate over all relvars you can define.
> Balancing all of those things, I think the relation alone delivers
> maximum value for minimum pain.

Well, then, qed ;-)

> A relational database has a set of
> relvars, a set of types, and that's all.
> Thus concludes my nonscientific rambling.
> - erk

cheers! --dawn Received on Wed Oct 27 2004 - 21:41:38 CEST

Original text of this message