Re: Unknown SQL

In article <EqCR6.749$n55.181258384_at_radon.golden.net>, Bob Badour says...
>
>>>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

In other words, there is a table from which delete oroginated and those deletes propagate to Students and Classes, right? For example if we add Universities table which is in one-to-many to Classes and Students. This diamond shaped relation schema is pretty often occur in the practice, btw.

>but only when the last of either class or student is deleted.

I dont understand. If we delete a university we have to delete anything below it, otherwise we have a serious data consistency problem.

>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.
>
Good point, I didn't notice that. Therefore, in object terminology, there would be an Enrollment object sitting in the database still connected to a Class and at the same time having null reference to a Student -- something that relationist would dismiss as semantic nonsence (null itself is a good enough indicator;-). Received on Sun Jul 22 2001 - 01:28:17 CEST