Re: Unknown SQL

>>Carl Rosenberger wrote in message <9f44gm$go2$03$1_at_news.t-online.com>...
>>>What do you do, if two references to the same child are possible?
>>
>>"Child" is a network model or hierarchic model concept. If one relation
 has
>>a constraint that at least one row must exist in two or more specified
>>tables, I would suggest that the data model is poorly designed to begin
>>with. Straw man.
>>
>If this is a typical many-to-many example like this:
>
>table Students;
>table Classes;
>table Enrollments;
>
>then whenever deleting a student we would probably want to cascade to
>Enrollments, even though this enrollment is "referenced" by some Class (not
 oo
>class, thanks god;-). David Cressey posted very good guidelines when we
 want to
>cascade delete in some old thread. Anyhow, there doesn't seem to be any
 logical
>problems associated with cascading deletes, as Carl suggested.

Carl hinted at situations where one would cascade delete from both Classes and Students but only when the last of either class or student is deleted. It makes sense to have a cascade delete from both Students and Classes in the many-many situation because each enrollment is truly dependent on both a class and a student.

If the class is cancelled, you will want to delete all the enrollments. Whenever you delete a student, you no longer need to know about any of the student's enrollments.

OODBMSs use garbage collection, however, and Carl was trying to make a claim that garbage collection is easier or more intuitive than cascading deletes. In an OODBMS, the DBMS will not delete the enrollment until all the references to it are gone. IE. one must delete both the student and the class before the enrollment disappears. Received on Sun Jul 22 2001 - 01:28:05 CEST