妥善处理复杂业务系统中的“删除”

删除的分类

什么是软删除
软删除又叫逻辑删除，标记删除，与我们常说的删除不同，并不是真的从数据库中将这条记录去除，而是会设置一个字段，比如：isDeleted来标记删除状态。

那就会产生下一个问题，为什么要有软删除呢？为什么不直接删除呢？

为什么会有软删除
在现实情况中，很多时候我们说的删除并不是真的是删除的本意，因为站在用户的角度来看，并不是一种删除的状态：

订单不是被删除的，是被“取消”的。
员工不是被删除的，是被“解雇”的（也可能是退休了）。

或者从程序设计的角度看

在复杂的业务中，一个关联的数据被删除了，那么数据的完整性就无法保证。产生的后果，就是无处不在的null 和bug。

在数据统计或账目核算的时候，不会被删除的数据影响。

所以这些时候，我们并不能真的把记录删除，所以软删除就出现了。

当然，我们更希望用一下代表状态的词来代替isDelete，就比如我们项目中已经使用的：有效、停用、弃用等等。

与硬删除的比较
虽然软删除比较好，它能保证数据的完整性，但并不表示我们任何时候都要使用软删除。当我们确定某些数据真的不需要的时候，硬删除就成了必须。比如验证码。这种数据删除后就没有必要保存了。

如何在业务系统中设计“删除”

1.系统中应该是软删除和硬删除并存的。根据实际情况合理的处理。
2.与业务无关，的数据直接硬删除，避免脏数据对系统查询的影响。
3.业务参与的数据，采用软删除，保证数据的完整和一致性。

如何在业务系统中设计“软删除”

在项目中，碰到了如下场景：

表1 资源表

image.png

表2 资源类型表

image.png

我们做了资源管理和资源类型管理的功能。

管理，就是增删查改，那么问题来了：
1.资源类型能删除吗？
2.资源能删除吗？

不管是按客户的需求，或是设计上的合理性，不管是资源类型，还是资源，都是可以删除的。所以既让用户可以删除数据，又要保证数据的完整性，软删除就成了最好的选择。

实际操作

增

已经被软删除的数据，用户不可见，无法再加入到业务系统。

删

isDeleted=true 跟外键无关

改

给予用户的选择，是排除软删除的数据。但是用户如果不改动以前的依赖数据，而以前的数据是已被软删除，可根据实际情况提示用户或者忽略。

查

不做软删除限制，保留数据完整性