Re: By The Dawn's Normal Light

From: Marshall Spight <mspight_at_dnai.com>
Date: Sat, 23 Oct 2004 18:42:33 GMT
Message-ID: <tCxed.294876$MQ5.202563_at_attbi_s52>


"Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message news:cldvjl$hj9$1_at_news.netins.net...

>

> 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. That
> is, does it make sense for the databases to handle ordered lists as one of
> the possible collections it will store? --dawn

It *certainly* makes sense for the database to handle ordered lists as one of the collection types.

I note that lists are actually a lot simpler than relations, in that they are generally defined in terms of element-at-a-time operations (as opposed to collection-at-a-time.) The basic operations are

get(position)
insert(position, element)
delete(position)
[and maybe size()]

and anything else you may want (concatenate, find, etc.) can be defined in terms of these.

This is somewhat (but not a lot!) simpler than the relational algebra: select, project, join, difference.

Note that we can simply ignore list position, and do our own duplicate removal, and pretend a list is a set. Likewise, we can create a relation (position, element) and do our own order management, and pretend it's a list. Neither is much fun, though.

I do think it makes sense to have a list type convertible to a relation and vice versa; it might also make sense to allow relational operations on a "relational view" of a list, although I understand there are some implementation complexities there.

We should probably start talking about what the nested relational model would look like, and what operations it would support. I understand academia has been over this ground a lot....

Marshall Received on Sat Oct 23 2004 - 20:42:33 CEST

Original text of this message