Есть ли проблемы с этим «Soft Delete» решением с использованием таблиц EAV?

Question

Я прочитал некоторую информацию об уродливой стороне просто установки поля deleted_at в ваших таблицах, чтобы показать, что строка была удалена.

А именно
http://richarddingwall.name/2009/11/20/the-trouble-with-soft-delete/

Есть ли потенциальные проблемы с извлечением строки из таблицы, которую вы хотите удалить, и ее переносом в некоторые таблицы EAV?

Например.

Скажем, у меня есть две таблицы deleted и deleted_row соответственно, описанные следующим образом.

    mysql> describe deleted;
    +------------+--------------+------+-----+---------+----------------+
    | Field      | Type         | Null | Key | Default | Extra          |
    +------------+--------------+------+-----+---------+----------------+
    | id         | int(11)      | NO   | PRI | NULL    | auto_increment | 
    | tablename  | varchar(255) | YES  |     | NULL    |                | 
    | deleted_at | timestamp    | YES  |     | NULL    |                | 
    +------------+--------------+------+-----+---------+----------------+

    mysql> describe deleted_rows;
    +--------+--------------+------+-----+---------+----------------+
    | Field  | Type         | Null | Key | Default | Extra          |
    +--------+--------------+------+-----+---------+----------------+
    | id     | int(11)      | NO   | PRI | NULL    | auto_increment | 
    | entity | int(11)      | YES  | MUL | NULL    |                | 
    | name   | varchar(255) | YES  |     | NULL    |                | 
    | value  | blob         | YES  |     | NULL    |                | 
    +--------+--------------+------+-----+---------+----------------+

Теперь, когда вы хотите удалить строку из любой таблицы, вы должны удалить ее из таблицы, а затем вставить ее в эти таблицы как таковые.

    deleted
    +----+-----------+---------------------+
    | id | tablename | deleted_at          |
    +----+-----------+---------------------+
    |  1 | products  | 2011-03-23 00:00:00 | 
    +----+-----------+---------------------+

    deleted_row
    +----+--------+-------------+-------------------------------+
    | id | entity | name        | value                         |
    +----+--------+-------------+-------------------------------+
    |  1 |      1 | Title       | A Great Product               | 
    |  2 |      1 | Price       | 55.00                         | 
    |  3 |      1 | Description | You guessed it... it's great. | 
    +----+--------+-------------+-------------------------------+

Несколько вещей, которые я вижу в летучей мыши.

1. Вам нужно будет использовать логику приложения. сделать поворот (Ruby, PHP, Python, и т.д.)
2. Стол может стать довольно большим потому что я использую blob для обработки неизвестный размер значения строки

Видите ли вы какие-либо другие явные проблемы с этим типом мягкого удаления?

Answer 1

Почему бы не отразить ваши таблицы с помощью архивных таблиц?

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)
)

А затем просто добавить триггеры on-delete-в ваши таблицы, которые вставляют текущую строку в зеркальную таблицу перед удалением? Это даст вам очень простое и очень эффективное решение.

Вы можете сгенерировать таблицы и код триггера, используя словарь данных.

Обратите внимание, что я, возможно, не захочу иметь уникальный индекс для исходного первичного ключа (col_1) в таблице архива, потому что вы можете в конечном итоге удалить одну и ту же строку дважды с течением времени, если вы используете естественные ключи. Если вы не планируете подключать архивные таблицы в своем приложении (для отмены), вы можете полностью удалить индекс. Кроме того, я добавил время удаления (delete_dtm) и суррогатный ключ, который можно использовать для удаления удаленных (хе-хе) строк.

Вы можете также рассмотреть возможность разбиения таблицы архива на удаленном_dtm. Это значительно облегчает очистку данных из таблиц.