Re: By The Dawn's Normal Light

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Wed, 27 Oct 2004 13:50:17 -0500
Message-ID: <cloqlr$k9n$1_at_news.netins.net>


"erk" <eric.kaun_at_pnc.com> wrote in message news:1098897766.696933.308200_at_c13g2000cwb.googlegroups.com...

Good to "see" you again, erk.
> > However, at least Date then defines (or re-defines) a
> > relation with some rigidity and claims that the only structure other
> than a
> > scalar value (which differs from an atomic value in some way I cannot
> > recall) for an attribute is his def of a relation. These claims are
> not
> > backed up with any mathematics, logic, nor even experiment, as best
> > I can tell.
>
> They're not; he's simply defining relational data management as having
> 2 "domain types": scalars and relations.
>
> > The argument is that if we have a relational engine for our
> > relations, then we can use that for nested relations as well. Sure,
> but if
> > we can help the developer with more structures, then why not do that.
>
> Well, we've been through this, but basically because those structures
> aren't helpful. Or at least of insufficient value to warrant
> complicating the data model.
>
> > Let's have the computer do more work so the analyst doesn't have to.
>
> Agreed, but the work can be done in terms of relations. The exception
> is reporting and display; then order matters (because a human is
> looking at it).
>
> > On to lists -- how much agreement is there on this list that having
> "the
> > computer" handle insertion, addition, and removal from ordered lists
> > rather than having developers do their own ordering algorithms, makes
>
> > sense.
>
> Sure it does, in the programming realm. That order just isn't
> significant for data management. Furthermore, the details of order can
> be relegated to the types; see Java's Comparable interface and
> "compareTo" method, for example.

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?

> > That is, does it make sense for the databases to handle ordered lists
> as
> > one of the possible collections it will store?
>
> It can if you want it to; I can certainly understand a DBMS vendor
> offering lists as a built-in type. But it's not important for the DBMS
> to know any more about the List than about the Set or the Date or
> the... offering them would just be a convenience. It doesn't affect
> relational theory or practice.

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? Thanks. --dawn

> - erk
>
Received on Wed Oct 27 2004 - 20:50:17 CEST

Original text of this message