Soft Delete vs. DB Archive

Question

Рекомендуемое чтение

Похоже: Является ли софт удаляет хорошую идею? Хорошая статья: http://weblogs.asp.net/fbouma/archive/2009/02/19/soft-deletes-are-bad-m-kay.aspx

Как я здесь оказался

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

Это привело к некоторому содроганию при взгляде на типичный подход удаления, CASCADE. Yikes, немного сверх того для моей текущей ситуации. Я хотел сохранить целостность реляционного графа, но я не хотел удалять каждый граф только потому, что одна часть цепочки была неактуальной. Поэтому я решил пойти по пути мягкого удаления, чтобы убедиться, что целостность данных сохранится, а записи могут быть удалены из релевантности. Я сделал это, добавив поле «DateDeleted» в каждую , вздох, таблицу в базе данных.

Поворотная точка

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

При поиске погоды или нет людей, подобных мягкому удалению, кажется, что поддерживается поддержка. На самом деле, ссылка «Похожие» наверх содержит ответ «Я всегда мягко удаляю». Более того, большинство ответов там и вокруг SO включают какой-то подход «isDeleted» или «isActive».

Новая идея реализации

Ссылка "Хорошая статья" охватывает некоторые из проблем, с которыми я фактически столкнулся. Он также предлагает альтернативу мягкому удалению, которое я нашел с точки зрения передового опыта. Предлагается использовать «Архивируемую базу данных», которую я на самом деле рассматривал, рассматривая мягкое удаление. Причина, по которой я отказался, заключалась в том, что я ранее высказал мысль об удалении CASCADE. Я осторожен, чтобы удалить целые графики из базы данных, потому что одна часть цепочки удаляется. Однако этот график можно было бы сохранить хотя бы из архива, поэтому я не уверен, что это будет действительно так ужасно.

Перекресток

Так, я должен просто продолжать добавлять логику, логику, логику .... логику? Или мне следует подумать о создании архивной базы данных, в которой большая часть логики просто находилась бы в очень сложном классе управления графами для хранения / восстановления реляционных графов объектов? Последнее кажется мне лучшей практикой.

Answer 1

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

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

Что еще хуже, то для того, чтобы сопровождать логику мягкого удаления, нужно все время включать (много раз нарушая различные соглашения иреализации анти-паттернов) для учета возможных разрывов в графе объектов.Кроме того, что за бизнес-логика является «isDeleted»?!

Я считаю, что очень сильное решение этой проблемы, проблема удаления объекта при сохранении ссылочной целостности графа объекта, заключается в использовании архива.шаблон.При удалении объекта объект архивируется, а затем удаляется.Архивная база данных, зеркальная база данных с метаданными (временная структура базы данных может использоваться и очень важна здесь), затем получит объект, который будет заархивирован и восстановлен при необходимости.

Это делает его очень прямым, чтобы избежатьперечисление или включение удаленного объекта, поскольку соответствующая база данных больше не будет его содержать.Теперь та же логика, которая применялась при поиске «isDeleted», «isActive» или «DeletedDate», может быть применена в правильном месте (не везде) к внешним ключам извлеченных объектов.Когда присутствует внешний ключ, а объекта нет, то теперь есть логическое объяснение и логический набор опций.Покажите, что содержащий объект был удален, и некоторые действия: «Восстановить, Удалить текущий содержащий объект, Просмотр удален».Эти параметры могут быть выбраны пользователем или явно определены в коде в логической форме.В зависимости от того, насколько развита архивная база данных, возможно, существуют дополнительные параметры, например, кто ее удалил, когда, почему и т. Д. И т. Д.