Cascading Deletes

From: Todd Taylor <nospam.taylor.todd_at_home.nospam.com>
Date: Fri, 09 Feb 2001 23:22:33 GMT
Message-ID: <ZY_g6.255437$iy3.56695788_at_news1.rdc1.tn.home.com>


My company is having an internal discussion about whether or not the practice of using cascading deletes in a database is good or bad, and I wanted to get some outside opinions on the subject.

I am arguing that they should never be used.

I prefer that the database protect me or anyone else from inadvertantly deleting data. It is not very hard to type in (or develop) extra DELETE statements for x number of child tables when attempting to delete a row in a parent table.

Let's say that a bug has been found in an application ( never happens <grin>) and you have to go "behind the scenes" and remove some bad data. If you are not using cascading deletes, isn't it nice to know that you can't accidentally delete the good data? Yes it may be a little more cumbersome but the alternative could be asking the client if they have a good, recent backup.

The issue of protability is another argument against using them. Some databases do not support such a feature (MSSql 7.0 for example). This argument is a little weak though since you could likely accomplish this with a trigger.

The only arguments I have heard for using them is from developers who don't want to write the extra code. To me, that is a cop out for being lazy.

Please respond with any comments and /or counter arguments you may have. There are always at least two sides to every story and I would like to hear from them all.

Thank you,

Todd Taylor
ProActive Technology, LLC Received on Sat Feb 10 2001 - 00:22:33 CET

Original text of this message