Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.cw.net!cw.net!news-FFM2.ecrc.de!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 16:13:15 +0100 Organization: IDI/NTNU Lines: 45 Message-ID: References: <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> <1141393792.003417.56260@e56g2000cwe.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 1141398800 24961 129.241.111.99 (3 Mar 2006 15:13:20 GMT) X-Complaints-To: usenet@itea.ntnu.no NNTP-Posting-Date: Fri, 3 Mar 2006 15:13:20 +0000 (UTC) User-Agent: MicroPlanet-Gravity/2.60.2060 Xref: dp-news.maxwell.syr.edu comp.databases.theory:37188 In article <1141393792.003417.56260@e56g2000cwe.googlegroups.com>, dawnwolthuis@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