Re: MV Keys
Date: 2 Mar 2006 10:40:28 -0800
Jon Heggland wrote:
> In article <1141260473.796686.131530_at_u72g2000cwu.googlegroups.com>,
> marshall.spight_at_gmail.com says...
> > To my current way of thinking, there are only the two compound types:
> > list and set. There are certainly other ways of thinking, involving
> > perhaps bags or whatever (or even objects :-). And note that those
> > two are not minimal, insofar as lists can be implemented quite
> > soundly (but not conveniently) with sets, and sets can be
> > implemented quite conveniently (but not soundly) with lists.
> 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.)
A mathematician has the luxury of picking and choosing from among whatever conceptual structures he wants. He can blithely shift from one to the other, and the most he might ever have to do is prove the existence of a mapping.
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.
I haven't been happy with just lists. I also haven't been happy with just sets. Each is extremely useful; I don't want to live without either.
> > This is why I predict that, if we were given NFNF as an
> > option, we'd find that the sweet spot would be close to,
> > but not right at, fully 1NF. (Assuming availability of
> > join. If you don't have join, you can't easily recompose
> > decomposed relations.)
> This is exactly what Date has said for a long time, in his work on RVAs.
Cool. Good to hear.
Marshall Received on Thu Mar 02 2006 - 19:40:28 CET