Как облегчить «мягкое удаление» данных, а также «физическое удаление»?

Question

У меня есть база данных MySQL с таблицами, некоторые из которых связаны с внешними ключами.Ну, вы можете проверить пример ниже.

Мне нужно убедиться, что оба родитель-потомка могут быть удалены при необходимости.Но мне также нужно убедиться, что система выполнит мягкое удаление (просто отметьте как удалено без физического их удаления), чтобы мы могли восстановить данные или использовать их для анализа.

1. Я знаю, что могу легко удалить обоих родителей и детей, включив ON DELETE CASCADE.Но здесь я могу потерять тысячи данных навсегда и не смогу восстановить.Будет случайным, если удаление будет случайным.

2. Я знаю, что могу отключить ON DELETE CASCADE и добавить еще одно поле в таблицы базы данных, чтобы пометить записи deleted.Таким образом, если запись удалена, она будет просто помечена как удаленная и не будет отображаться в приложении, пока она будет представлена ​​в базе данных.Проблема в этом сценарии заключается в том, что если parent помечен как удаленный, то мне придется пометить все children как удаленные, по крайней мере, в моей системе.С другой стороны, если я физически захочу удалить записи, это будет довольно большой беспорядок, мне придется сначала удалить все child записей.

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

Наилучший вариант, который я могу придумать, представлен ниже.

1. Включить DELETE ON CASCADE.Но не выставляйте методы записи delete обычным пользователям.Предоставляйте эти методы только администраторам.

2. Добавьте delete_flag поле в таблицы.В этом поле будет указано, удалена запись или нет.Предоставьте эти методы как обычным пользователям, так и администраторам, так как это физически ничего не удалит.

Пожалуйста, дайте мне знать, хорош ли этот способ или у вас есть лучшие варианты?Также, если мой путь лучше, как обновить delete_flag ребенка, когда delete_flag родителей изменился?

Answer 1

Вот как я справляюсь с подобными вещами.

1. Как избежать CASCADE CONSTRAINT,

2. Я ставлю столбец expiry_datestamp на каждую таблицу.

3. Я настроил запросы к оперативным данным так: AND (expiry_datestamp IS NULL OR expiry_datestamp < NOW())

4. При мягком удалении строк я использую UPDATE ... SET expiry_datestamp = NOW()

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

6. Я создаю программы очистки, для которых значение DELETE истекловещи, явно удаляя дочерние записи перед родительскими записями.(Не полагаясь на функциональность CASCADE CONSTRAINT).Эти программы могут запускаться ежемесячно или еженедельно, или по любому графику, который вам необходим.

7. Фильтр (x IS NULL OR x < NOW()) может быть упрощен, если вы установите значения expiry_date в новых записях на определенную дату далеков будущем.

Примечание.Конечно, вы можете использовать столбец deleted вместо моего более сложного подхода expiry_date. Если вы делаете , убедитесь, что ваши запросы говорят AND deleted = 0 вместо AND deleted <> 1.Фильтры неравенства работают не так хорошо, как фильтры равенства.

О GDPR: Это реальная проблема и боль в шее.Если ваша политика гласит, что вы удаляете личную информацию через три месяца после того, как пользователь в последний раз вводит ее, то вы можете заставить свои программы очистки выполнять эту операцию.Вы правы в том, что информация о продукте не является личной информацией.

Редактировать : Моя процедура: я не хочу предоставлять пользователю веб-приложения привилегии MySQL только для строк со сложным удалениеммягко-УДАЛИТЬ их.В моем рабочем процессе безопаснее делать это при чистке с более высокими привилегиями.Я избегаю CASCADE CONSTRAINTS, потому что мне не нравятся побочные эффекты: я хочу ловить и останавливать DELETE (или UPDATE), когда они нарушают ограничения.Я считаю, что более безопасная и лучшая практика программирования - создание процедур очистки для явного удаления зависимых строк.

У вас могут быть разные предпочтения.