Uh uh... I don't let user's make changes directly to the data in the database. The extra layer of abstraction is more an overture to the stupidity of FUTURE users, not the current one. This guy's actually quite intelligent, especially compared to the average joe luser.
Basically, data in the system goes back and forth like this:
USER <---> FLATFILE TEXT <---> DATABASE
The user can either create new data to input in the database, or they can pull data from the database. Either way, the data they actually edit is ALWAYS in the FLATFILE TEXT stage. That way, I can say "look - you can muck around with it however you want, just don't commit the changes until you're CERTAIN that's what you want to do". Even then, there's a window of several hours before the changes really do commit for most edits (deletion of textual data is an exception). It also makes it virtually impossible to delete content from the databse unintentionally (database data is absolutely sacred in this case - it MUST not be spoiled for good reason).
This guy, however, made changes to about 20 documents or more over a period of maybe 4 hours. Then, he went to commit them all at the same time, accidentally chose to delete it, and wiped out ALL of his draft work. Since it was all from scratch, it didn't exist in any form anywhere else, so it was gone

I tried some heroic efforts, but, ultimately, it was consigned to the ultimate data afterworld: bit bucket... bummer. It was a poor design decision on my part to not verify the removal, and to not put a limit on how many can be deleted at one time - two things that have since changed!
Still, although I trust the current guy to not fudge things up, I have taken into consideration future waves of idiots who may take over and basically made it as simplistic as possible.... I don't trust the average user as far as I can throw 'im...