Re: MV Keys

From: Marshall Spight <marshall.spight_at_gmail.com>
Date: 3 Mar 2006 10:17:56 -0800
Message-ID: <1141409876.758527.66510_at_i39g2000cwa.googlegroups.com>


Jon Heggland wrote:

>

> Anyway, a counterargument is that introducing lists implies more
> complexity, less simplicity, and no change in power---the users gets the
> additional burden of having to learn all the list operators, when they
> don't really have to.

That's a decent argument, but I think in the final analysis it doesn't hold up. Lists are really quite simple, so they don't add much cognitive load. Indeed, those from outside the RM world are already used to using lists for pretty much everything already, whether appropriate or not. The cost of having to learn all the list operators is prepaid, and was pocket change to begin with.

> I'm not sure I buy this argument myself (even
> though it is one of Date's:)---but on the other hand, I've never really
> missed lists in my databases. I can order my data any way I want; why
> would I want to have one particular order represented implicitly,
> treating it as somehow more "important" than the others?

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

> 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. I think this is what Dawn means when she talks about "interface."

Marshall Received on Fri Mar 03 2006 - 19:17:56 CET

Original text of this message