Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!udel!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!bg0l+ From: bg0l+@andrew.cmu.edu (Bruce E. Golightly) Newsgroups: comp.databases Subject: Re: Ingres Question: Duplicate Rows Message-ID: Date: 23 Sep 90 21:22:55 GMT References: <1990Aug8.230913.2897@agate.berkeley.edu> <26867@pasteur.Berkeley.EDU>, <12314@blia.BLI.COM> Organization: Carnegie Mellon, Pittsburgh, PA Lines: 19 In-Reply-To: <12314@blia.BLI.COM> While the definition of RDBMS may preclude duplicate rows, the real world certainly does not! During the original development of the telecommunications data bases for the university (over four years ago!), this fact cost me some gray hairs that I could ill afford. The granularityh of the telephone reporting mechanisms available from Bell permits apparent duplicates. The development of an RDBMS based system to replace COBOL and flat files was held up at one point because there really were duplicates in the data. As far as the phone system was concerned, there were two calls that originated from the same extension to the same external number at the same time and with the same duration. This seemingly impossible phenomenon was the result of two extremely short calls. Other examples can surely b contributed by the community. The ANSI standard allows duplicates because the real world must cope with things that are identical for all intents and purposes. If the model doesn't allow the developer and/or user to get close enough to handling the real world, it must ultimately be discarded.