Path: utzoo!mnetor!uunet!husc6!yale!cmcl2!nrl-cmf!ames!oliveb!sun!yosemite!trogers
From: trogers%yosemite@Sun.COM (Tom Rogers)
Newsgroups: comp.databases
Subject: Re: Referential Integrity Constraints
Message-ID: <45529@sun.uucp>
Date: 15 Mar 88 15:51:24 GMT
Sender: news@sun.uucp
Lines: 29
Keywords: Referential Integrity, SunUnify, Databrowse, cascade, SQL2

In article <1401@polyslo.UUCP>, lchirica@polyslo.UUCP (Laurian Chirica) writes:
> 
> In article <502@ashton.UUCP> cy@ashtate.UUCP (Cy Shuster) writes:
> >I'm surprised you had to write code for a CODASYL DBMS to enforce
> >cascaded deletes. In the IDMS implementation, ....
> 
> No, I think I stated the opposite: I damaged a database due to
> cascaded deletes.  That's why I am very uncomfortable with cascaded
> deletes/updates in relational databases.  I do not know of any relational
> DBMS that performs cascaded deletes, but I have seen some proposals in
> various papers.  

Although SunUnify does not perform cascaded deletes, Databrowse (an
entity-relationship editor/browser written on top of the ERIC interface to
SunUnify) will cascade deletes or updates upon confirmation. We find this to 
be a very useful feature. There have been no problems using it, and it has not
corrupted any databases. SunUnify does not allow cycles in reference graphs.
I could imagine potential problems with cascading operations when cycles could
be defined in reference graphs. Note that of this writing, cascaded deletes and 
updates (with cycles) are being included in SQL2.

>As a "compromise" the syntax should differentiate
> between a simple delete request which is rejected if a referential
> constraint is violated (eg. UNIFY) and a cascaded delete which goes
> ahead and (potentially) empties out the whole database (eg. ???).

If you could empty a database with a cascaded delete, you would most likely 
have a one-entity database. Otherwise, you would have a database admin
without a job if it happened more than once :-).