【问题标题】：Soft Delete vs. DB Archive软删除与数据库存档
【发布时间】：2012-04-10 10:59:45
【问题描述】：
推荐阅读
类似：Are soft deletes a good idea?
好文章：http://weblogs.asp.net/fbouma/archive/2009/02/19/soft-deletes-are-bad-m-kay.aspx
我是怎么来到这里的
我坚信，在制作软件时，任何事前为尽量减少以后的工作而做的事情都会在卡车负载中得到回报。因此，我试图确保在处理我的数据库架构和维护时，它可以保持关系完整性，同时不会过时或过于复杂。
当看到典型的删除方法 CASCADE 时，这导致了一种不寒而栗。哎呀，我目前的情况有点过头了。我想保持关系图的完整性，但我不想仅仅因为链的一部分不相关而删除每个图。因此，我选择了软删除的方式，以确保数据的完整性保持不变，而记录可以从相关性中删除。我通过将“DateDeleted”字段添加到数据库中的每个，叹息，表来完成此操作。
转折点
然而，这显然开始增加太多的复杂性和工作是值得的。我在不应该去的地方加入了逻辑，并且不想在我的整个应用程序中延续这些不良做法。简而言之，我将回滚这个实现。
当查找天气或不喜欢软删除的人时，似乎有很多支持它。事实上，链接的“类似”帖子顶部显示了“我总是软删除”的最高投票答案。此外，那里和 SO 周围的大多数答案都包括某种“isDeleted”或“isActive”类型的方法。
新的实施思路
链接的“好文章”涵盖了我实际开始遇到的一些问题。它还提出了一种软删除的替代方法，我从最佳实践的角度发现了这种方法。建议是使用“存档数据库”，我在查看软删除时实际上已经考虑过。我决定反对它的原因是因为我之前提到的关于 CASCADE 删除的观点。我很谨慎地从数据库中删除整个图表，因为链的一部分被删除了。但是，这个图表至少可以从存档中保留下来，所以我不确定它是否真的那么糟糕。
十字路口
那么，我应该继续添加逻辑、逻辑、逻辑……逻辑吗？或者，我是否应该考虑将大部分逻辑放在一个非常复杂的图形管理类中来存储/恢复关系对象图的存档数据库？后者对我来说似乎是最佳实践。
【问题讨论】：
标签：
relational-database
soft-delete
【解决方案1】：
理论上，软删除绝对是一种简单的方法。但是，并没有真正关注如何处理未删除的数据。事实上，它被掩盖了。
在我看来，这是因为关注了错误的问题。不仅仅是“删除意味着什么”，还有正在删除的内容。当要删除一条记录时，真正要删除的是图中的一个节点——而不仅仅是一条记录。整个图的完整性是人们用“软删除”来解决问题的原因。这些创可贴解决方案往往会将坏疽隐藏在下面——这个问题只会随着时间的推移变得更糟。
更糟糕的是，为了伴随软删除，必须全部包含逻辑（多次打破各种约定并实施反模式）以解决对象图中可能出现的中断。而且，“isDeleted”是个什么样的业务逻辑？！
我相信这个问题的一个非常强大的解决方案，即在保留对象图的引用完整性的同时删除对象的问题，是使用归档模式。在删除对象时，该对象被归档然后被删除。存档数据库，一个带有元数据的镜像数据库（可以使用临时数据库设计，在这里非常相关），然后会在必要时接收要存档和恢复的对象。
这使得避免列出或包含已删除对象非常直接，因为相关数据库将不再保存它。现在，用于查找“isDeleted”、“isActive”或“DeletedDate”的相同逻辑可以应用于检索对象的外键的正确位置（不是所有位置）。当存在外键但对象不存在时，现在有一个合乎逻辑的解释和一组合乎逻辑的选项。显示包含对象已被删除以及一些操作过程：“恢复，删除当前包含对象，查看已删除”。这些选项可以由用户选择，也可以在代码中以逻辑方式明确定义。根据档案数据库的先进程度，可能存在更多选项，例如谁删除它、何时删除、为什么删除等等。