Re: MV Keys

In article <1141324828.479189.199000_at_i40g2000cwc.googlegroups.com>, marshall.spight_at_gmail.com says...
> Jon Heggland wrote:
> > So it is essentially an arbitrary decision? Why make it, then?
>
> One necessarily makes a decision. The designers of SQL
> chose only a single unordered collection. The designers of
> Java chose only a single, ordered collection. (I'm referring
> to the array; Java has certainly thrown an impressive
> assortment of collections into the core API, but in-a-library
> is not the same thing as in-the-language; all Java collections
> are built on arrays and objects.)

Arrays *or* objects, I think you mean. (And arrays are objects as well.) I don't really see the significance of how the collections are implemented internally; half the point of OO is to make this irrelevant anyway. And is the library/language distinction really that clear cut? Is the String class in the language or in the library?

In any case, that wasn't really what I meant to ask. It seems you say that compound types breaks 1NF, but that it doesn't really matter much; and that the classification of types into compound and simple is essentially arbitrary. What, then, is the use of talking about 1NF and simple vs compound types at all?

> I am not a mathematician. I am a software engineer.
> I have to deal with implementation, so I don't necessarily
> want to include everything I can think of. At the same time,
> I want to optimize the power:complexity ratio the
> programmer has available.

This is the same argument Date uses to espouse the relation type (or type generator) as the only compound attribute type (generator)---it introduces minimal extra complexity, since relations and relational operators have to exist anyway, and it can handle both lists and sets. :)

-- 
Jon