关于数据库逻辑删除（伪删除）的设计方案探讨

大家好，又见面了，我是你们的朋友全栈君。

项目上碰到过关于数据采用了逻辑删除导致的问题，情况是这样：原先的代码中，对于表T中的数据的删除采用的是逻辑删除，但是其他使用该数据的地方并没有针对逻辑删除进行配套的处理。该表T中存在字段A 要求不能重复，其实就是说字段A是unique key。

那么问题就来了，逻辑删除只是将数据的status字段更新为删除状态，所以字段A的旧值依然存在，导致插入新数据时，就不能使用已经删除的字段A的值，这明显是不合理的。由于这里采用逻辑删除，同时还引入了关联关系也未进行物理删除的问题。就该场景，本人进行了一番关于逻辑删除的思考，在此抛砖引玉，欢迎讨论。

首先要思考要不要用逻辑删除

这一点很重要，不要盲目使用逻辑删除，首先要看是否有必要采用逻辑删除。因为采用物理删除的优势是显而易见的，不会有历史数据，数据间的关联关系也不会出错，还能节省数据库空间。采用物理删除，业务处理起来很清爽。所以如果没有必要，那么可以优先采用物理删除，从而避免逻辑删除引入的麻烦。比如说本人这次碰到的情况，实际上项目中并不需要逻辑删除，没有这方面需求，这些历史数据也没什么价值。所以这个问题就是当初的开发人员盲目采用了逻辑删除，而没有考虑周全导致的。基于这个情况，直接修改为物理删除解决问题。

当然，某些情况下必须使用逻辑删除，尤其是在现在越来越注重数据价值的环境下。比如历史数据有价值，项目对历史数据有存档要求，或者需要历史数据进行恢复等， 这些情况就必须采用逻辑删除了。

那么逻辑删除该采用怎样的设计呢？

方案1：增加delete_token字段（需要设置默认值，如“defaultToken”），与原来的unique key 组成联合主键.

delete_token字段作用：用来标识该条记录被删除，而不是通过原来的status或enabled字段来区分该记录是否已删除。

比如本文开头我碰到的情况，可以增加一个字段delete_token字段，与原来的字段A组成联合主键。比如删除表T中数据记录1时，delete_token可以更新为该条记录的主键id或者生成的唯一随机值（如UUID），用该方案可解决不能插入已删除数据的问题。同时也要注意，表T的关联关系表也需要进行类似的处理。

优点：不需要引入新表

缺点：若业务量较大或增删频繁，那么数据增长速度会很快，导致一张表中数据量太大，对表的操作效率会降低。

结论：适用于数据量较小、增删不频繁的场景。

方案2：增加备份表（删除记录表）

每张表都设计一张对应的备份表，用于存储删除的数据。表结构可以根据实际需要在原表基础上增加删除时间、删除操作者之类的字段。这样在删除数据时，对于原表，相当于是物理删除，然后再备份表中插入新的记录。注意：关联关系表也需要备份表。

优点：跟物理删除类似，不会有数据冲突的问题。同时也满足了逻辑删除的需求。将在用的业务数据与历史数据区分开，业务结构更清晰。

缺点：需要逻辑删除的数据都要有对应备份表。

结论：推荐该方案。

最后总结：推荐方案2，若大家有更好的方案，欢迎讨论。

参考资料：

https://www.jianshu.com/p/f37281576585