Should I delete or disable a row in a relational d

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 just ignore it?

For example, if I wanted to remove a user from a program.

Answer 1

This should be determined by the application needs. I have done it both ways. I have some applications that need to support undo as the cost of removing a row -- and the cascading deletes that are caused by that -- are too expensive to not have it. Normally, though, the applications I have done require the user to confirm deletes, then just do as the user has asked. In some cases, you must delete the data due to privacy concerns. That is, if the user requests to be removed, you need to really remove it, not just mark it as not current. In other cases (like tax-related transactions), there may be reasons to keep data in a non-current state until no longer required by law. I have applications that fit in both categories.

Various strategies can be used in the case where you need to keep "archival" data. Depending on whether it needs to be immediately available you can push it to archive tables that are either kept or backed up and cleaned out regularly. If there is a need for undo you may want to keep it in the current table and just mark it by setting a flag. It really depends on the complexity of your schema, the requirements of the application, and personal preference to some extent.

Answer 2

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.

Answer 3

Adding a "DELETED" column to your table and marking rows instead of deleting them creates a lot more work for you with little (if any) benefit. Now, every time you write a query you have to remember to include "WHERE DELETED IS NOT NULL" (or whatever).

A better approach is to delete data when you need to delete data, and rely on your regular backup process to ensure that no data is ever lost. If for some reason you need to keep some deleted data handy (for searches, maybe), you're better off just copying the data to a different table created for this purpose and then deleting the originals.

I've inherited many databases over the years, and this strategy of flagging records instead of deleting them is unfortunately very common, and (in my experience at least) always leads to major problems down the road.

Answer 4

It's probably best to add "deleted" column and offer users to undelete or purge deleted items.

Answer 5

If you do use a deleted, visible, isactive, etc column, you can abstract away having to remember to use it by using views.

Answer 6

I am creating a CRUD and i'm facing the same problem.

Solution : The D of CRUD should disable instead of delete.

Problems:

• "Every" query should check if the registry is disable or not (flag=1 for example). More specifically, ever select * should check that.
• Every insert should activate the registry (flag=1) by default.
• Update shouldn't change the flag.
• Disable is an update in disguise that marks the flag=0.

Big Problem

• Garbage collector. Exists three strategies : to delete old registries, to delete registries that are not referenced or a mix of strategies.