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

Marshall Spight wrote:
> Anthony W. Youngman wrote:

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

There is more to it.

[forced meaning/overspecification]
The above is one way of expressing the list as a set. There are other ways, and that is where the complication comes in. One has to decide which.

First, the way you chose is not without problems:

Let's put a new element 'N' into
the list, right after the 'B':

The new list is [A, B, N, C].
Now what is the set?

is it UC1: { (1, A), (2, B), (3, C), (2.5, N) } or is it UC2: { (1, A), (2, B), (4, C), (3, N) } ?

In the case of UC1 we will have to make sure that there is allways room for inserts, In the case of UC2 every insert causes updates to all elements that should be after the new element.

Now there are other ways of representing lists as unordered collection, better or worse at some or other aspects - but that is not the problem.

The problem is we have to make a choice with consequences to get from the list to a unordered collection carrying the same meaning, so we are capable of reconstructing the list. It is a strange thing: we require an 'unordered collection' to preserve order - now if that isn't asking for trouble ... :-) but I am digressing.

Thing is we *have* to make a complex choice, because (and only because) we decided that the order was meaningful. But the choice we have to make has *more* consequences than we bargained for. I could imagine people calling that 'extra data' - but what does the extra data mean? In the above solutions we get an extra column (or attribute) stating rank. In another solution we might get an extra colmunn designating the 'next in order' element - or would 'prior' be better?

I don't care, but I must decide.
It is somewhat like having to choose which side on the road to drive on without traffic signs and without knowing what country you are in.

There are even more worms in this can, I think, but I would appreciate your comments on this one.

<snip>
> 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?

Lisp and prolog come to mind - but that is not what you are looking for - at least it is not what I am looking for. Received on Sun Jun 27 2004 - 11:51:11 CEST