Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!nisca.ircc.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!hellgate.utah.edu!cc.utah.edu!inel.gov!gem-hy!cdm From: cdm@gem-hy.Berkeley.EDU (Dale Cook) Newsgroups: comp.databases Subject: Re: Ingres Question: Duplicate Rows Message-ID: <1990Sep27.191853.14153@inel.gov> Date: 27 Sep 90 19:18:53 GMT References: <1990Aug8.230913.2897@agate.berkeley.edu> <26867@pasteur.Berkeley.EDU>, <12314@blia.BLI.COM> Sender: news@inel.gov Reply-To: cdm@gem-hy.Berkeley.EDU (Dale Cook) Organization: Idaho National Engineering Laboratory, Idaho Falls, Idaho Lines: 49 In article , bg0l+@andrew.cmu.edu (Bruce E. Golightly) writes: |> 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. Sorry, but I disagree. If you have two identical rows, you have not sufficiently identified your primary key. Data analysis techniques I am familiar with would indicate a dumb sequence number as the best alternative for the situation you describe. Note that there is no requirement that you ever use this primary key, but its existence is a logical requirement, for lack of a better one. Dale Cook Neither the United States Government nor the Idaho National Engineering Laboratory nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the Idaho National Engineering Laboratory. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the Idaho National Engineering Laboratory, and shall not be used for advertising or product endorsement purposes.