Re: MV Keys

In article <1141659907.033197.11480_at_e56g2000cwe.googlegroups.com>, marshall.spight_at_gmail.com says...
> Jon Heggland wrote:
> > You seem to be saying here that lists is the
> > right way to handle ordered data, and sets (relations) is the wrong way.
> > Which means that relations almost never should be used; after all,
> > almost all my relvars contain ordered data: ordered by name, or by date,
> > or by importance, or ...
>
> No no no! What you are describing is sets. If you have some
> attribute(s)
> of the data that has one or more associated orders, that doesn't mean
> it's a list; that only means that it's sortable. A list is something
> different; it's a data structure that has implicit order in addition
> to the fact that it's elements may be sortable.

All right, that clears it up for me a bit: Ordered data is something with an *implicit* order. But I note that there are always facilities for making the order explicit: Strings have operators for determining the nth character, or the position(s) of a given character. To me, this is not very different from a relational view of strings.

> This is a list:
> [ 'h', 'e', 'l', 'l', 'o']
>
> This is a set
> {'h', 'e', 'o' 'l'}
>
> You can sort either one of them. But only the first one is uniquely
> "hello".

Of course, they don't represent the same information.

> And for the record, I'd say that unordered data structures are
> extremely common.

I'd say that orderedness is just a property of how we choose to represent our data, not an inherent property of the data itself. If we make the ordering explicit, the data becomes unordered, if I understand you correctly---yet the information is unchanged.

Anyway, we are bickering over details here. I entered this discussion to refute the claim that list attributes breaks the RM, and I don't think my quarrel lies with you. :)

-- 
Jon