Re: Cascading Deletes

I always set 'on delete restrict'. I'm a cautious man by nature. Found myself coding triggers to prevent cascading (if exists child records signal exception) working with legacy app. It's a definetly tough question. Theory says enforce this at lowest possible level - RDBMS. Practice says, users will mess, and you are to blame. I administer about 15 db's, involved in replication, and any change in shema is big big big big trouble, especially with 24x7 db, with table sizes in range of millions of rows. I work as a developer too, and have direct contacts with customers. Seen every aspect of this dilema, and still I'm confused about this. I've learned one thing though: it's not the question of what is right, but who is to blame if something goes wrong. Let that be user, not you. Give her/him 3 warnings before she/he can delete multiple records. That's business, we are live from money customer pays. I'm interested in any expirience others have with this matter.

Through application logic, you definetly have more control in your hand, even if that means writing few lines of code. I hope I won't get flamed for this :)

Goran

Todd Taylor wrote in message ...
...

>You have found the meat of the question, where do you draw the line between
>yes it's ok and no it's not? Granted, some situations make it mighty
>tempting to use them. However, customers almost always change their minds,
>even on rules that are "set in stone". This could easily make a cascading
>delete invalid, which means a change in the datamodel; and we all know that
>sometimes even a simple change to the datamodel can have a far reaching
>impact on any number of applications.
>
>Again, I will counter with this: How hard is it to write an extra DELETE
>statement or two. From what I have found, most of these "qualified"
>situations are header/detail where all anyone is trying to get out of is
>writing the following:
>
>DELETE from tblDetail where parentID = x;
>
>Why people would prefer to risk inadvertant data loss in order to keep from
>having to write the above line of code is beyond me.
>
>I thank you for the response. This is exactly what prompted the discussion
>at my office.
>
>
>TNT
>
>
Received on Tue Feb 13 2001 - 10:59:35 CET