Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!usc!ucsd!helios.ee.lbl.gov!pasteur!eden!mao
From: mao@eden (Mike Olson)
Newsgroups: comp.databases
Subject: Re: Ingres Question: Duplicate Rows
Summary: duplicates, yikes
Message-ID: <26867@pasteur.Berkeley.EDU>
Date: 9 Aug 90 03:03:41 GMT
References: <1990Aug8.230913.2897@agate.berkeley.edu>
Sender: news@pasteur.Berkeley.EDU
Reply-To: mao@postgres.Berkeley.EDU (Mike Olson)
Followup-To: comp.databases
Organization: University of California, Berkeley
Lines: 27
X-Local-Date: 8 Aug 90 20:03:41 PDT


In <1990Aug8.230913.2897@agate.berkeley.edu>, steve@violet.berkeley.edu
(Steve Goldfield) writes:

> Does anyone know whether the unwanted suppression of duplicate
> rows is a bug or a feature? If it is a feature, it seems
> an undesireable one to me, since I can think of lots of
> situations where I would like to allow the possibility of
> duplicate rows. It seems bothersome to have to include an
> unwanted column in a table just to keep the rows unique.

i can't comment on what ingres is doing in its heap access method, but
as a general statement, duplicate rows in relational systems are a major
no-no.  codd explains why in grueling detail in his books; basically,
it comes down to the fact that different access paths can yield different
results if duplicates are permitted.  the fact that most commercial systems
(well, okay, all commercial systems) permit dups is testimony to the
difficulty of detecting and removing them, and not to their desirability.

you shouldn't be encoding meaning into dups.  you can add a "number of
occurrences" column to rows in the table if you really want to know how
many occurrences there are.

					mike olson
					postgres research group
					uc berkeley
					mao@postgres.berkeley.edu