Как обрабатывать УДАЛЕНИЯ в базе данных (перемещение удаленного объекта в архивную таблицу)?

Question

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

В нашем случае, что будет удалено пользователями, это своего рода «работа», которую мы выполняем для наших клиентов.Как только работа завершена, пользователи обычно не хотят, чтобы она была указана на веб-странице, поэтому они удаляют ее.Сначала (когда система находилась в фазе тестирования, чтобы не было никакого вреда), удаление пользователя было настоящим УДАЛЕНИЕМ из базы данных.Поскольку он был прекрасно настроен на каскад до самого низа нашего графа сущностей, он действительно удалил все.И тоже заняло много времени.Теперь, когда мы начали использовать систему по-настоящему, я боялся случайных удалений и сделал невозможным для пользователей что-либо удалять.

Я думаю, что самый важный вопрос: «Что именно означает« удаление »работы в нашей сфере бизнеса?»В нашем случае есть два момента:

• Пользователи больше не хотят видеть список работ (если они явно не запрашивают список старых работ, который я поэтому должен сохранить)
• Некоторые данные задания утеряны навсегда, и сохраняется только некоторый базовый обзор статуса задания

Я прочитал много статей о том, почему мягкое удаление хорошо, и много опочему это не так (например, здесь ).То, что мне кажется лучшей альтернативой, - это перемещение удаленного задания в какую-либо архивную таблицу.В то же время я бы удалил данные задания, которые больше не нужны.Хорошим следствием этого является то, что мне не придется настраивать все мои запросы для обработки какого-либо столбца «DeletedOn», и основная таблица заданий не будет загромождена неактивными заданиями.

Проблема, с которой я столкнулся при этомэто скорее технический вопрос: если я все еще хочу сохранить ссылки на другие объекты на удаленную работу, каков наилучший способ сделать это?Поскольку у меня есть внешние ключи для таблицы заданий, настроенной в других объектах, я не могу просто переместить задание в другую таблицу, DB не разрешит мне.

Каков обычный и хорошо проверенный подход к этому?

Answer 1

ЕСЛИ я вас правильно понимаю, тогда у вас есть какие-то «задания» в БД, и вы не можете удалить всю связанную информацию, но вам необходимо сохранить некоторую их часть ...

В таких случаях я использую два варианта:

• Добавить поле состояния вакансии
  Это поле может иметь различные значения, такие как новое / в процессе / ожидание / доставлено / удалено ... как только вы измените свой код, чтобы приспособить для этого нового поля, у вас будет много гибкости ... вы можете предложить фильтры на основе состояния задания для пользователь в интерфейсе и т. д.

• Добавить поле DeleteOn и скрыть его
  Вы переименовываете таблицу, добавляете поле и создаете представление с тем же именем, что и исходная таблица, которая отфильтровывает все записи с установленным параметром DeleteOn ... представление получает триггер (ON DELETE), который просто устанавливает это поле для соответствующего задания. .. не каскадное удаление, не загромождение / изменение кода и т. д. Если это необходимо, вы всегда можете расширить триггер, чтобы переместить все или часть строк, для которых DeleteOn установлен в архивные таблицы ...

Answer 2

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

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

• Переместить данные
• Пометить данные как удаленные и отфильтровать их при каждом запросе

Теперь вопрос того, что для вас дороже.

• Перемещение данных: здесь вам понадобится еще одна таблица (или база данных OLAP?) Для сохранения всех удалений.Первая цена, которая приходит мне в голову - это двойное обслуживание.Если вы добавляете столбец в одну таблицу, вы должны добавить его в хронологическую таблицу (или обновить задание ETL и целевую таблицу).Каждое изменение, которое вы вносите в свою ERD, должно быть сделано дважды.

• Пометить данные: обновите все текущие запросы, чтобы учесть флаг.Это может быть болезненно, но это один час (и в большинстве случаев это будет WHERE deleted = 0). Некоторые ORM предоставляют хорошие подходы для решения этой проблемы без необходимости вручную изменять запросы.Еще одна проблема, о которой вы также упомянули, ваши таблицы будут «грязными».Это может или не может быть проблемой производительности в зависимости от объема данных, которые вы генерируете.

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