Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.media.kyoto-u.ac.jp!newsfeed.vmunix.org!uio.no!ntnu.no!not-for-mail From: Jon Heggland Newsgroups: comp.databases.theory Subject: Re: MV Keys Date: Fri, 3 Mar 2006 08:01:55 +0100 Organization: IDI/NTNU Lines: 38 Message-ID: References: <1140883592.060038.188390@z34g2000cwc.googlegroups.com> <1140886408.778878.179090@i39g2000cwa.googlegroups.com> <1140915349.609443.285650@e56g2000cwe.googlegroups.com> <1140916287.800990.284570@t39g2000cwt.googlegroups.com> <1140928045.223226.301140@i40g2000cwc.googlegroups.com> <440185c0$0$11076$e4fe514c@news.xs4all.nl> <1140963712.820976.72300@u72g2000cwu.googlegroups.com> <4401cd8b$0$11062$e4fe514c@news.xs4all.nl> <1140981916.897576.34490@u72g2000cwu.googlegroups.com> <1141000908.277461.101140@t39g2000cwt.googlegroups.com> <1141180942.125742.288830@j33g2000cwa.googlegroups.com> <1141239957.788010.239620@j33g2000cwa.googlegroups.com> <1141260473.796686.131530@u72g2000cwu.googlegroups.com> <1141324828.479189.199000@i40g2000cwc.googlegroups.com> NNTP-Posting-Host: coleburn.idi.ntnu.no Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Trace: orkan.itea.ntnu.no 1141372919 10510 129.241.111.99 (3 Mar 2006 08:01:59 GMT) X-Complaints-To: usenet@itea.ntnu.no NNTP-Posting-Date: Fri, 3 Mar 2006 08:01:59 +0000 (UTC) User-Agent: MicroPlanet-Gravity/2.60.2060 Xref: dp-news.maxwell.syr.edu comp.databases.theory:37167 In article <1141324828.479189.199000@i40g2000cwc.googlegroups.com>, marshall.spight@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