To Delete, or Not to Delete

To delete or not to delete? That is the (programming) question I’m trying to answer.

Lately I’ve been doing some work on a desktop application that uses a database to store things, and I’ve run up against an age-old question:

To Delete, or Not to Delete?

There is a school of thought that says if you’re going to store things in a database, don’t ever delete them – just flag them as “deleted” or “hidden” and don’t show them unless you do something special. After all, disk space is cheap and that way you can save yourself from embarrassing accidents where you accidentally delete something you didn’t mean to (even the recycle bin can’t save you from every accidental deletion, after all).

Then there is a different school of thought that says if you’re going to delete something – really delete it! Don’t lie to the user and “hide” it and make the user pay the penalty of the disk space/performance overhead/etc. for things they think they’ve gotten rid of permanently. (There’s also an issue of data privacy to consider here as well – if you don’t delete things, and those things contain sensitive information – say, passwords, social security numbers, etc. – is that “right?”)

I’m mostly in the 2nd camp – if I want things to stick around after I’ve deleted them, I’ll explicitly allow for it, though either a backup system (Mozy) or version control (Subversion). Otherwise, when I delete something, I expect it to be really deleted!

Of course, in keeping with the idea of “strong opinions, weakly held,” I do have to consider the possibility of going the other way. And honestly, it’s a hard decision to make. There is no “right” answer – there are trade-offs on both ends.

Which camp are you in – the “keep everything” camp or the “deleted means deleted” camp?

Author: Keith Survell

A geek, programmer, amateur photographer, anime fan and crazy rabbit person.