Re: MV Keys

Jon Heggland wrote:
> In article <1141409876.758527.66510_at_i39g2000cwa.googlegroups.com>,
> marshall.spight_at_gmail.com says...
> > Again, my couterargument: if sets were really the right way
> > to handle ordered data, we'd represent strings as relations
> > of (foreign key, position, char).
>
> Isn't this a bit extreme?

Well, yes, it's extreme; that's the point. 1NF is an extreme position; the above highlights just how extreme it is.

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

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

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

> > > I also think that keeping the internals of a DBMS simple is a good
> > > idea---for the benefit of the optimiser, if nothing else. It is trivial
> > > to implement sets using relations; implementing lists should not be much
> > > harder.
> >
> > Jan Hidders has also made this point on a number of occasions, but
> > I don't agree. The thing we most want to optimize for is the
> > experience of the user of the language--power, expressiveness,
> > whatever you want to call it.
>
> But not performance? Anyway, I don't think we necessarily have to choose
> either one or the other.

Agreed.

Marshall Received on Mon Mar 06 2006 - 09:45:07 CST