Мягкое удаление, вероятно, того не стоит. Или «переосмыслите свой столбец delete_at» Перевод

20 Июля 2022 11:42

Любой, кто видел пару разных сред производственной базы данных, вероятно, знаком с шаблоном «мягкого удаления» — вместо удаления данных напрямую с помощью DELETE оператора таблицы получают дополнительную deleted_at метку времени, а удаление выполняется с оператором обновления:

UPDATE foo SET deleted_at = now() WHERE id = $1;

Концепция мягкого удаления заключается в том, чтобы сделать удаление более безопасным и обратимым. После того, как запись была повреждена DELETE, ее технически все еще можно восстановить, покопавшись в слое хранилища, но достаточно сказать, что ее действительно трудно восстановить. Теоретически при мягком удалении вы просто deleted_at вернетесь к NULL и все готово:

-- and like magic, it's back!!
UPDATE foo SET deleted_at = NULL WHERE id = $1;

Недостатки: утечка кода

Но у техники есть существенные недостатки. Во-первых, логика мягкого удаления проникает во все части вашего кода. Все наши выборки выглядят примерно так:

SELECT *
FROM customer
WHERE id = @id
    AND deleted_at IS NULL;

И забывание этого дополнительного предиката deleted_at может иметь опасные последствия, поскольку он случайно возвращает данные, которые больше не предназначены для просмотра.

Восстановление действительно работает?

Опять же, мягкое удаление теоретически является защитой от случайной потери данных. В качестве последнего аргумента против этого я бы попросил вас реально рассмотреть вопрос о том, действительно ли когда-либо выполнялось отмену удаления.

  • Когда я работал в Heroku, мы использовали мягкое удаление.
  • Когда я работал в Stripe, мы использовали мягкое удаление.
  • На моей работе сейчас мы используем мягкое удаление.

Насколько мне известно, ни разу за десять с лишним лет никто в любом из этих мест не использовал мягкое удаление для восстановления чего-либо.

Основная причина этого заключается в том, что удаление данных почти всегда имеет побочные эффекты, не связанные с данными.

https://brandur.org/soft-deletion

Yori Yori + 997

3 Ответа

  1. Evg Evg 20 Июля 2022 12:23 (ред.)

    Хм. Очень странно. Я использую мягкое удаление на многих проектах. В Discourse его применяют часто, но, ИМХО, в статье не указан еще один пункт, а он очень важен. Даже не восстановление важно, а история.

    Пример, где я могу нажать на любую вкладку и увидить удаленный контент и понять / вспомнить почему это вообще произошло. К тому же, с url в частности, такой способ удаление бьет с тем, что не должно быть 2 url с одного сайта. Дублей сайтов не должно быть.

    Был, например, занесен сайт, мы удалили его, и после этого больше никто не сможет добавить его. Rambler top100 так было сделано. Это частный случай использование истории.

    Конечно, отдельный разговор про реализацию этого дела. Все по разному на самом деле делают.

  1. German German 20 Июля 2022 22:03

    А что у нас с Syntax Highlighter? Штормит.

  1. Evg Evg 20 Июля 2022 22:16

    Старый вариант 50 классов добавляет. А GeSHi, сейчас буду пробовать:

    $geshi->enable_classes();

    чтобы политику вернуть назад, пока все так себе. )