Re: MV Keys

In article <1141393792.003417.56260_at_e56g2000cwe.googlegroups.com>, dawnwolthuis_at_gmail.com says...
> While I don't think 1NF is a goal, and I am not settled on how scalar
> and/or atomic values are best defined, I do think there is some sense
> in having such a concept. There is a difference between a logical data
> model where a list of e-mail addresses is modeled as a list attribute
> of a Person or as a simple/scalar/atomic attribute of a separate
> PersonEmail.

Certainly (though they can represent exactly the same information). I just think that calling this distinction a normal form, or saying that one of these models is anathema to the RM, doesn't make much sense.

> This issue of minimizing complexity is confusing. A logical data model
> is implemented by developers using an interface to a dbms. There are
> trade-offs in any design, of course, and if we are going to build a
> house with round walls it will cost additional dollars. But we don't
> want dbms tool designers to suggest they will be making design
> decisions based on simplifying the design for the computer or for the
> dbms developers. The simplicity we need to care about a bit more is
> the simplicity for the user of the tools. I think that is where
> Marshall's use of the term "power" comes in. Surely you can implement
> a list, for example, using the RM, but the tool is not doing much work
> for you. It doesn't have enough power. It isn't simple enough from a
> user standpoint.

Yeah... is C more powerful than assembler? Is it simpler? :) I prefer high-level/low-level rather than power/simplicity as terms for such considerations.

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

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.

-- 
Jon