Re: In an RDBMS, what does "Data" mean?

From: Marshall Spight <mspight_at_dnai.com>
Date: Sun, 27 Jun 2004 01:42:08 GMT
Message-ID: <QBpDc.122156$Sw.52192_at_attbi_s51>

"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:1aPaN6Am2x0AFwN3_at_thewolery.demon.co.uk...

>

> Note that it's easy to go from a list to either of the other two. But in
> order to go back, the set or bag needs to contain extra data (ie the
> order) over the list.

I don't see how you could consider that data "extra" if it was there originally.

Anyway, the list [A, B, C] expressed as a set is { (1, A), (2, B), (3, C) } where [] denotes an ordered collection and {} denotes an unordered collection.

Going back to the list from the information-preserving set is not that hard.

> Because Pick stores attributes as lists (if relevant) the order is
> available to the db engine as metadata if required. And it can't be
> accidentally lost by an analyst :-) So I would argue that storing things
> as lists is better, because you can always get the other two if you
> want.

Although I don't think having lists as the only collection primitive is a good idea, there is one key point that I will gladly grant you:

Lists are very common, and SQL doesn't handle them well at all. RM doesn't handle them well either.

(I can also believe that MV handles them quite well, although I have no direct experience to that end.)

Does anyone know of a "list calculus" or "list algebra" with a formal definition? It is just too simple for anyone to have cared about?

Marshall Received on Sun Jun 27 2004 - 03:42:08 CEST