Thinking outside the box

Patron Saint of Lost Yaks
posts - 202, comments - 734, trackbacks - 4

My Links

Advertisement

News

Archives

Post Categories
<< Curiosity found, the wrap | Home | Microsoft SQL Server Action Figure >>

Finding table reference levels and simulating cascading deletes

I worked with this topic recent weekend and posted the final functions here
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=97454
 

The general idea is to have a generic purge functionality.

Print | posted on Saturday, February 16, 2008 7:32 PM | Filed Under [ SQL Server 2008 Algorithms Administration SQL Server 2005 SQL Server 2000 ]

Feedback

Gravatar

# re: Finding table reference levels and simulating cascading deletes

I understand why some people might want this, but I think it is truly a bad idea to even do something like this. A good database developer/dba should know their relationships in the database and should always explicitly do the delete statements. I believe it will perform better, protects against potential bugs in code, and is just the correct way. One should never depend on Cascade deleting it is just a bad practice. I always have cascades disabled.
2/16/2008 11:43 PM | Jason
Gravatar

# re: Finding table reference levels and simulating cascading deletes

It is not necessarily a bad idea.
Sometime you want to purge old data from a system.

In this case, there was a need to purge customers who had a certain statusid and had hold that statusid for a period of time.

This particular system is sprung from a "off-the-shelf" product but has many modules installed specialized for this customer.

Instead of having to maintain a "purge" sproc and make sure ALL involved developers over time (8 years) added their tables to this sproc, I thought I could make a generic function to create all necessary delete statements for me.
2/17/2008 10:59 AM | Peso
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET

Copyright © Peter Larsson