PL/SQL on delete cascade.. ( how to view the child record deleted..?)

Question

Hai
i have 70 tables integrated with foreign and child key constraints. i have on delete cascade for all the child tables. if i delete the parent table automatically child table record get deleted.
Kindly tell me how can i check howmany child record has been deleted ..? how can i monitor this...?
one thing i can do... i can make count of child table before and after...
is there anyother way..?
S

Answer 1

Peter,
I subscribe to the general consensus around trigger usage. Allthough I allways diffentiate between triggers that,
- perform pl/sql with embedded DML (that is: delete, insert, update)
versus triggers
- that perform pl/sql with embedded queries only.
The latter use of triggers is good (in my opinion), and most frequently used to enforce (non declarable) data integrity constraints.
The former use of triggers is bad. Because it makes things happen automagically.
Just google "asktom triggers are evil", you'll find statements such as:
~quote
because things happen automagically
because side effects are bad
because explicit linear code is more maintainable then "happens as a by product of something in the background"
magic should be avoided. Experience tells me this.
~quote
And to me a CASCADE DELETE clause on a foreign key definition, is a TRIGGER. Allbeit not one for which you had to write CREATE TRIGGER statements, but one that you can declaratively introduce. And this trigger holds embedded DML, it is of the former case, and is therefor bad.
You the designer of the application may be aware that you have your FK's as cascade delete. But your successor(s) might not be aware of this when they write maintenance code to delete Orders. They might be expecting the database to throw them an FK violation message when they try to delete an Order that still has Lines attached to it.
Everybody knows the effect of an INSERT, a DELETE, an UPDATE. But the moment you've introduced triggers with embedded DML in them, the effect of these three well known primitive SQL statements suddenly becomes unknown. With triggers you can create any effect for any of these three primitives, that you want. And more often than not other people maintaining your codebase later on in the future, do not realize these side effects happen, because they didn't check the presence of any triggers, nor investigated the side effects caused by them.
Btw. for exactly the same reasoning I consider use of DEFAULT-clause on table columns, or even use of (fixed length) CHAR datatype, evil also. Again they are in effect declarative triggers with side effects. Allbeit that their side effects usually are less worse than those caused by handwritten triggers with embedded DML.
Toon