Re: MV Keys

Jon Heggland wrote:
> 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?

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.

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

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.

Cheers! --dawn Received on Fri Mar 03 2006 - 14:49:52 CET