Re: Unknown SQL

>>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?

Nope. Carl hinted at a situation where I delete a Class and the Enrollments hang around or I delete a Student and the Enrollments hang around. Only when I delete both the Class and the Student will the DBMS remove the Enrollment. This is how garbage collection would work.

Carl was trying to claim that cascaded deletes are problematic and difficult when, in fact, they are not.

>>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.

University is irrelevant. As I mentioned in my earlier message, if a design had such a constraint as Carl hinted at, I would consider it a poor design. I think you would too, which is why you have trouble understanding the issue. It would never occur to you to construct such a situation.

The garbage collection algorithm is simply incorrect for almost all similar situations; it leads to inconsistent, corrupt data. I think that's too high a price to pay to save writing a couple of lines of code.

>>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;-).

Yes, exactly! Carl will tell you that this nonsense situation is a good thing because the programmer doesn't have to think about anything. The OODBMS just "takes care of it" -- albeit incorrectly.

What Carl fails to realise or seeks to avoid is: Programmers are required to think in order to perform their jobs. High quality, correct code does not happen by magic.

He also fails to realise that proper normalization obviates the "problem" in the first place. He claims that learning normalization is a difficult concept and that programmers should perform data modelling in complete ignorance of it.

The fact that learning normalization will cause programmers to make better object designs is totally anathema to him.

I am sure that every programmer has worked with someone at some point in their career who claimed to be a programmer, who:

• does not understand scope of operation
• does not know the difference between references and values
• cannot devise simple algorithms on their own
• cannot identify special cases or error prone situations for debugging
• writes code by trying different things at random until something seems to work

When otherwise good programmers treat normalization as something to avoid, they reveal themselves as the data modelling equivalent of the above type of programmer.

Carl's message is dangerously seductive. Received on Sun Jul 22 2001 - 01:28:18 CEST