Are there problems with this 'Soft Delete' solution using EAV tables?

Question

I\'ve read some information about the ugly side of just setting a deleted_at field in your tables to signify a row has been deleted.

Namely
http://richa

Answer 1

Why not mirror your tables with archive tables?

create table mytable(
   col_1 int
  ,col_2 varchar(100)
  ,col_3 date 
  ,primary key(col_1)
)

create table mytable_deleted(
   delete_id  int      not null auto_increment
  ,delete_dtm datetime not null
-- All of the original columns
  ,col_1 int
  ,col_2 varchar(100)
  ,col_3 date 
  ,index(col_1)
  ,primary key(delete_id)
)

And then simply add on-delete-triggers on your tables that inserts the current row in the mirrored table before the deletion? That would provide you with dead-simple and very performant solution.

You could actually generate the tables and trigger code using the data dictionary.

Note that I might not want to have a unique index on the original primary key (col_1) in the archive table, because you may actually end up deleting the same row twice over time if you are using natural keys. Unless you plan to hook up the archive tables in your application (for undo purposes) you can drop the index entirely. Also, I added the time of delete (deleted_dtm) and a surrogate key that can be used to delete the deleted (hehe) rows.

You may also consider range partitioning the archive table on deleted_dtm. This makes it pretty much effortless to purge data from the tables.