推荐阅读
我为什么会来到这里
我坚信，制作软件时，任何早期的工作都能在以后的工作中大量减轻负担。因此，在处理数据库架构和维护时，我试图确保它能维护关系完整性，同时又不过时或过于复杂。
这导致了我对典型的删除方法（CASCADE）感到惊慌失措。哇，这有点过头了。在我的当前情况下，我想维护关系图形的完整性，但我不想因为链中的一部分无关紧要而删除每个图形。因此，我选择了采用软删除方式，以确保数据完整性得到维护，同时可以从相关性方面删除记录。我通过向数据库中的每个表添加“DateDeleted”字段来实现这一点。
转折点
然而，这显然开始增加太多的复杂性和工作量，不值得。我正在包含不应该存在的逻辑，并且不希望在整个应用程序中延续这些不良惯例。简而言之，我将回滚此实现。
当查找人们是否喜欢软删除时，似乎有很多支持它的人。事实上，顶部投票答案为“我总是软删除”的链接“类似”文章。此外，在那里和SO周围的大多数答案都包括某种“isDeleted”或“isActive”类型的方法。
新实现想法
所链接的“好文章”涵盖了我实际遇到的一些问题。从最佳实践的角度来看，它还提出了软删除的替代方案，我认为非常准确。建议使用“归档数据库”，我实际上在考虑软删除时就已经考虑过这一点。我决定反对它的原因是我之前关于CASCADE删除的观点。我不愿意从数据库中删除整个图形，因为链的一部分被删除了。然而，这个图形至少可以从归档中保留，所以我不确定它是否真的那么可怕。
十字路口
因此，我应该继续添加逻辑、逻辑、逻辑....逻辑吗？还是应该考虑创建归档数据库，让大部分逻辑仅在一个非常复杂的图形管理类中存储/恢复关系对象图形？对我来说，后者似乎是最佳实践。