Обратимое удаление и архив БД

Рекомендуемая литература

  • Аналогично: Обратимое удаление — хорошая идея?
  • Хорошая статья: http://weblogs.asp.net/fbouma/archive/2009/02/19/soft-deletes-are-bad-m-kay.aspx
  • Как я здесь оказался

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

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

    Поворотный момент

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

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

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

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

    Перекрёсток

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

    7
    задан Community 23 May 2017 в 12:31
    поделиться