Re: By The Dawn's Normal Light

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

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

• erk