在进行逻辑删除时保持一致性答案

【问题标题】：Maintaining consistency when doing logical delete在进行逻辑删除时保持一致性
【发布时间】：2014-09-23 14:39:38
【问题描述】：

当一个项目应该从数据库中删除时，我正在执行逻辑删除。

我在每个需要执行逻辑删除的表中添加了一个额外的DateTime 列。因此，在删除时，您只需更新字段，例如...

UPDATE Client 
SET deleted = GETDATE() 
WHERE Client.CID = @cid

以后如果应该恢复的话……

UPDATE Client 
SET deleted = NULL 
WHERE Client.CID = @cid

所以典型的选择语句看起来像......

SELECT * 
FROM client 
WHERE CID = @cid AND deleted IS NULL

但问题是如何处理依赖关系以在这种方法中保持数据库的一致性。例如。在删除（实际更新）员工之前，我必须做几项检查，例如查看与被删除员工有关的相关表格中是否有任何相关的出勤/银行账户/工资数据/历史等。

那么做这些事情的正常做法是什么？我需要检查所有的东西吗

IF EXISTS (SELECT...)

声明？

编辑：

如果我想在有相关记录时阻止更新，我可以使用 UNION 执行类似的操作...

IF NOT EXISTS (SELECT emp_id FROM BankAccount WHERE emp_id = '100' UNION SELECT EID FROM Attendance WHERE EID = '100' UNION SELECT employee_id FROM SalaryTrans WHERE employee_id = '100')
UPDATE Employee SET Employee.deleted = GETDATE() WHERE emp_id = '100'

这是一个可以接受的解决方案吗？

【问题讨论】：

如果其他表中有相关记录，是否要防止删除？还是要级联删除？
@Aheho，我只想在大多数情况下防止删除。例如。谈到员工和薪水。

标签： sql sql-server database relationship

【解决方案1】：

但问题是如何处理依赖关系来维护在这种方法中数据库的一致性。例如。删除前（实际上是更新）一个员工我必须做一些检查，比如看看有没有相关的考勤/银行账户/工资与员工相关的相关表格中的数据/历史记录等已删除。

那么做这些事情的正常做法是什么？

这完全取决于您的应用程序。

有些公司可能会要求在删除一个人之前“处理”所有待处理的工资、累积的休假天数和病假天数等。 已处理 可能意味着将所有这些东西转换为金钱，然后添加到最终的薪水中。其他公司可能随时允许删除，因为他们知道逻辑删除不会影响其他表中的任何相关行。应用程序代码应该知道如何处理对已删除人员的最终检查。

其他应用程序可能无法处理像工资和税收这样重要的事情。他们可能允许随时进行逻辑删除，而不必担心微不足道的后果。

【讨论】：

【解决方案2】：

查看触发器，它们在这里可能会有所帮助。

您可以在您的员工表上定义一个触发器，以检查您的逻辑删除是否会导致其他表出现问题。它涉及手动跟踪哪些表需要访问员工，因此它不像允许外键约束为您跟踪它那样健壮，但它可以工作。如果发现另一个表引用了员工，我会将其设置为“AFTER UPDATE”触发器并回滚事务（在触发器内）。如果他们试图实际删除在 FK 约束中使用的员工，他们无论如何都会得到回滚，所以这没什么不同。

另一种方法是使用 AFTER DELETE 触发器将已删除的员工复制到“deleted_employees”表中，这样您仍然可以使用它们，但是通过 FK 引用该员工的任何表都会出错并回滚事务在您的触发器甚至有机会运行之前。

我必须在我的一些内容中使用与您建议的逻辑类似的逻辑（每次使用时都检查一下），并且大多数情况下我包括一个位字段“IsDead”，我在删除记录时设置，然后每次使用该表时，我都必须参考。但我主要构建视图，因为我的架构很复杂，并且在视图的 where 子句中包含 IsDead = 0 很简单。我不知道 IsDead = 0 与 DelDate IS NULL 相比如何，如果你有一个大型数据库，你可以测试一下。

【讨论】：