Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ub!canisius!pavlov
From: pavlov@canisius.UUCP (Greg Pavlov)
Newsgroups: comp.databases
Subject: Re: SQL Duplicate Row Deletion ???
Message-ID: <3319@canisius.UUCP>
Date: 8 Apr 91 06:14:49 GMT
References: <91091.141528SYSPMZT@GECRDVM1.BITNET> <1991Apr3.085710.57@cim-vax.honeywell.com>
Organization: Canisius College, Buffalo N.Y. 14208
Lines: 25

In article <1991Apr3.085710.57@cim-vax.honeywell.com>, tdoyle@cim-vax.honeywell.com writes:
> > 	I am now using Ingres, I am surprised that it allows the user to append 
> > duplicated rows (including a null row) into a table unless you define a key
> > using create unique index.
> > 
> In a "clean" database implementation there is NO excuse for such behavior,
> but alas it is simple/machine efficient? for DBMS vendors to do it this way.
> 
  Ignoring the "theoretical" argument of what an "attribute" really is, I would
  argue very strongly that I do NOT want my DBMS to make such assumptions. 
  INGRES generally provides one with the tools to enforce whatever "view" of 
  "good" database "practice" one may have and one can use them accordingly. 
  But that does not mean that a given person's "view" is useful, optimal, or
  even "correct".  

  In our shop, for instance, all tables are required to have
  unique keys.  But if we receive a m{ae}ss of data from elsewhere that has to
  be manipulated, massaged, etc, to get it into a workable form, we first load
  it in "raw" into temporary tables to see what we actually have and to use
  INGRES itself to perform the reformatting/transformation.  During this work,
  I don't want INGRES to make any other-view presuppositions about what we
  should/should not be doing.

  greg pavlov, fstrf, amherst, ny
  pavlov@stewart.fstrf.org