Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!pmafire!mica.inel.gov!gem-hy!cdm
From: cdm@gem-hy.Inel.GOV (Dale Cook)
Newsgroups: comp.databases
Subject: Re: SQL Duplicate Row Deletion ???
Message-ID: <1991Apr8.155156.14251@inel.gov>
Date: 8 Apr 91 15:51:56 GMT
References: <91091.141528SYSPMZT@GECRDVM1.BITNET> <1991Apr3.010838.2063@eng.ufl.edu> <1991Apr3.085710.57@cim-vax.honeywell.com> <1991Apr4.004438.15592@inel.gov> <1991Apr5.074844.59@cim-vax.honeywell.com>
Sender: news@inel.gov
Reply-To: cdm@gem-hy.Inel.GOV (Dale Cook)
Organization: Idaho National Engineering Laboratory, Idaho Falls, Idaho
Lines: 65

In article <1991Apr5.074844.59@cim-vax.honeywell.com>,
tdoyle@cim-vax.honeywell.com writes:
|> In article <1991Apr4.004438.15592@inel.gov>, cdm@gem-hy.Inel.GOV
(Dale Cook) writes:
|> > 
|> > Sorry, but I must disagree.  Attributes do not _identify_ an
instance of an
|> > entity, they merely describe it.  A subtle, but important, distinction.
|> > There is nothing in data modelling that says multiple instances of
an entity
|> > or relationship cannot have identical attributes.
|> 
|> Attributes are the ONLY way to describe an object. You may CHOOSE to use the
                                  ^^^^^^^^
Isn't that what I said?

|> rowid as an additional attribute for the sake of convenience (or in some 
|> extreme case that I have not encountered, a necessity), but don't try
|> to pass that off as data modelling.

You're right; what I meant to do was make a distinction between describing
an instance of an object and identifying it.  Obviously, in order to make
use of rowid as the primary key, one should properly model the data in order
to come to the conclusion that a sequence number is an appropriate primary
key.  My implication was that the primary key was not an attribute; that
implication is false.  

But we digress.  The original question is whether a true RDBMS should allow
rows with identical attributes.  I still claim it should.  As long as the 
DBMS internally identifies the row uniquely, the implementation violates no
rules of normalization.  As long as the DBMS allows you the ability to 
create unique keys via some mechanism, the implementor has no problem.  To
enforce uniqueness between all identified attributes unnecessarily removes
a perfectly valid option to a database implementor.

As a matter of practicality as well, why should I pay for the DBMS to ensure
every row has at least one attribute with a different value, when I don't
need it?  What you are asking for is a unique index on the entire row.  Is
that what you want?  I really doubt it.

|> 
|> Note that the person who originally posted the request has now created a 
|> unique index to avoid the problem.
|>

Which is exactly what should have been done.  The real problem is not with
the DBMS; it is with unfounded expectations about the behavior of the DBMS.

----------------------------------------------------------------------
--- Dale Cook          "You can sum this game up in one word -
    cdm@inel.gov        'you never know'".  --- J. Andujar
The opinions are mine.  The following disclaimer is my employers.
----------------------------------------------------------------------
========== long legal disclaimer follows, press n to skip ===========

Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights.  No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory.  The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.