Wrote one of those many years ago, yes - for medical data. It's the right solution to just about every problem actually, and I'm surprised that it isn't more commonly taught.
One thing I haven't figured out is how to archive old records, I think it's not a problem for modern DBMSs, but we have a problem at work with 15 years' worth of historical data.
Comments
I did something similar about 10 years ago at my first dev job. I forgot a "WHERE" in an update and destroyed every customer in the live db.
The issue was that my manager never caught it in my migration file and it went live.
I was lucky that we backed up every day..and didn't really lose a ton of data.
We persuaded mySQL to add the --i-am-a-dummy (http://sql-info.de/mysql/notes/I-am-a-dummy.html) option after about the third time one of our developers did this.
I never really understood why databases don't have undo.
They do: http://www.oracle.com/technetwork/database/features/availabi...
I largely avoid UPDATE and DELETE statements. Changes are new rows, time ordered, which supersede prior rows. Like an audit log.
Works great. Especially for anything that needs history, e.g. medical data.
Wrote one of those many years ago, yes - for medical data. It's the right solution to just about every problem actually, and I'm surprised that it isn't more commonly taught.
Yeah, logical deletes ftw :) .
One thing I haven't figured out is how to archive old records, I think it's not a problem for modern DBMSs, but we have a problem at work with 15 years' worth of historical data.