Should I delete or disable a row in a relational database?

Question

In a brand new program where space isn\'t really that big a deal, is it better to delete a row or to disable a row by let\'s say a boolean \"Disabled\" and have the program

Answer 1

It depends. If it is disabled then it is easier to undelete / to see that someone actually deleted the record (for auditing).

You may also have a technical requirement to not delete records. For example, if you wanted to synchronize your database with another user by just sending changed records you wouldn't be able to do that if it was actually deleted.

Answer 2

Unless you have a specific need for managing your own deletions, you are better off just deleting the rows.

Answer 3

It's up to you and your requirements (some things get rather hard when records exist that...don't).

I will say that a boolean is a bad choice, though. Make it a nullable timestamp. It's pretty handy to know when something was deleted, especially when you deleted too much and want to undo part of the delete.

Answer 4

As many have already said, the application needs dictated what you want to do. But to me, marking a row seems like not using the right tool for the right thing. We logically think of a delete as a DELETE, so when if you are not allowed to delete for legal reasons, then you don't delete it in the first place. At the same time, i think about all the internal data structure keeping and indexing. Not to mention all the optimizations that can be done to retrieve data, but adding that check(in the view or in the query) affects the performance exponentially with the complexity of the database and the relations the entities have.

In a nutshell, put the deletion logic in the UI layer to prevent user errors and give delete permissions to users who should be able to delete it. Use regular backups for keeping archives. If your application absolutely requires a strict audit history, implement it in triggers and put the audit in an off-site database to avoid all that traffic, check and crap from the production.

Answer 5

I'd like to note that there are (in most countries) use-cases where you can't delete records for legal reasons. Industry and data dependant of course.

In this case I believe the best practice guidleine is to shadow table the "deleted" data which gains you the benefits of actual deletion outlined by MatthewMartin and by extension I have come to find this pattern frequently preferable to creating "active" bit-flags across my data-tables.

Answer 6

Not deleting will create a new class of bugs for all future queries. Don't forget that query writing is often done by power users (i.e. non-IT professionals), and junior developers. So now every table that has invalid data marked only by a BIT active flag will need an additional AND in the WHERE clause for every query from now until forever. This will help users fall into the pit of failure instead of the pit of success. However, I strongly encourage you to implement these flag systems anyhow because without bad design, there is no need for maintenance developers to fix the numerous bugs it will create.

How valuable is it to have historical data in the table? If the business if forward looking, having old data in the tables can just be a burden-- it cause problems when creating constraints (all constraints will have to be modified to exclude data you wish wasn't there). Data quality assurance is complicated by having to continually re-identify what is "old crap we are afraid to delete but never want to ever use or update again" and new stuff we care about.

Is it being deleted because it was a mistake? If the row corresponds to an entity in real life, maybe it is interesting to keep and set a "vaporized", "dead", "left the building" flag. If you accidentally inserted a row that corresponds to no entity in real life, a DELETE is not a bad thing. Are imaginary customers that never existed important to keep in the customer table?

And finally, personality plays a big role. People can be packrats with data, too. If a DBA keeps all his newspapers from 30 years back and don't like deleting data, maybe he should make sure he's making data design decisions based on the merits and not an irrelevant personal preference.