I have learned a very hard lesson.
The quick version is that I wrote a bit of code that, instead of deleting a single record from a database, cleared the table in the database. Yeah, oops. And this script was tied to a button that any user of a web application might click. While this might sound like a great subplot to Lost, it’s terrible for a web site.
Twice. People clicked it twice, and emptied all of our data. I was able to restore a backup once. We lost a lot of hard-earned information.
We all write bad code. Why I’m truly kicking myself is that I elsewhere in the application I’d been using Active/Inactive flags (“Click here to delete this item” marks the “Active” field to 0. “Click here to restore it” marks the “Active” field to 1.) rather than deleting records. I should’ve done this for all of my tables. Why I didn’t was a snap decision while coding, and of course I now regret it.
So I’m determined to never delete anything. Or overwrite it without a backup. For example, in another web app that writes XML files, I’m copying the existing files to a folder with a time stamp before overwriting them.
People talk about how cheap web space is now, and how fast our server are. There’s no reason to ever get rid of data. This holds true for building web apps.
This is a new “best practice” for me. I keep a short list of rules so I will never make this kind of bad “quick decision” again.
Tags: best practices, data recovery, database design, deleting database records
