relational-database - 软删除与数据库存档

Question

推荐阅读

类似：软删除是个好主意吗？

好文章：http ://weblogs.asp.net/fbouma/archive/2009/02/19/soft-deletes-are-bad-m-kay.aspx

我是怎么来到这里的

我坚信，在制作软件时，任何预先做的以尽量减少以后的工作都会在卡车负载中得到回报。因此，我试图确保在处理我的数据库架构和维护时，它可以保持关系完整性，同时不会过时或过于复杂。

当看到典型的删除方法 CASCADE 时，这导致了一种不寒而栗。哎呀，我目前的情况有点过头了。我想保持关系图的完整性，但我不想仅仅因为链的一部分不相关而删除每个图。因此，我选择了软删除的方式，以确保数据的完整性保持不变，而记录可以从相关性中删除。我通过向数据库中的每个sigh表添加一个“DateDeleted”字段来实现这一点。

转折点

然而，这显然开始增加太多的复杂性和工作是值得的。我在不应该去的地方加入了逻辑，并且不想在我的整个应用程序中延续这些不良做法。简而言之，我将回滚这个实现。

在查找天气时人们喜欢软删除，似乎有很多支持它。事实上，链接的“类似”帖子顶部显示了“我总是软删除”的最高投票答案。此外，那里和周围的大多数答案都包括某种“isDeleted”或“isActive”类型的方法。

新的实施理念

链接的“好文章”涵盖了我实际开始遇到的一些问题。它还提出了一种软删除的替代方法，我从最佳实践的角度发现了这种方法。建议是使用“存档数据库”，我在查看软删除时实际上已经考虑过。我决定反对它的原因是因为我之前提到的关于 CASCADE 删除的观点。我很谨慎地从数据库中删除整个图表，因为链的一部分被删除了。但是，这个图表至少可以从档案中保留下来，所以我不确定它是否真的那么糟糕。

十字路口

那么，我应该继续添加逻辑，逻辑，逻辑......逻辑吗？或者，我是否应该考虑将大部分逻辑放在一个非常复杂的图形管理类中来存储/恢复关系对象图的存档数据库？后者对我来说似乎是最佳实践。

Answer 1

理论上，软删除绝对是一种简单的方法。但是，并没有真正关注如何处理未删除的数据。事实上，它被掩盖了。

在我看来，这是因为关注了错误的问题。不仅仅是“删除意味着什么”，还有正在删除的内容。当要删除一条记录时，真正要删除的是图中的一个节点——而不仅仅是一条记录。整个图的完整性是人们用“软删除”来解决问题的原因。这些创可贴解决方案往往会将坏疽隐藏在下面——随着时间的推移，这个问题只会变得更糟。

更糟糕的是，为了伴随软删除，必须全面包含逻辑（多次打破各种约定并实施反模式），以解决对象图中可能出现的中断。而且，“isDeleted”是个什么样的业务逻辑？！

我相信这个问题的一个非常强大的解决方案，即在保留对象图的引用完整性的同时删除对象的问题，是使用归档模式。在删除对象时，该对象被归档然后被删除。存档数据库，一个带有元数据的镜像数据库（可以使用临时数据库设计，并且在这里非常相关），然后将在必要时接收要存档和恢复的对象。

这使得避免列出或包含已删除对象非常直接，因为相关数据库将不再保存它。现在，用于查找“isDeleted”、“isActive”或“DeletedDate”的相同逻辑可以应用于检索对象的外键的正确位置（不是所有位置）。当存在外键但对象不存在时，现在有一个合乎逻辑的解释和一组合乎逻辑的选项。显示包含对象已被删除以及一些操作过程：“恢复，删除当前包含对象，查看已删除”。这些选项可以由用户选择，也可以在代码中以逻辑方式明确定义。根据档案数据库的先进程度，可能存在更多选项，例如谁删除它、何时删除、为什么删除等。