数据库逻辑删除的解决方案探讨
数据库逻辑删除的解决方案探讨
该文章有很多废话，如果不想看，请直接点击目录: 我该怎么办？
为什么我会看到这篇文章?
你可能是一个程序员，在CSDN的搜索框上输入了“数据库逻辑删除解决方案”并点击了搜索按钮。
我遇到什么问题了？
在进行数据库设计时，你的公司认为数据对于公司来说存在重大意义(即便是已经删除的数据)，因此你被强制要求对于数据的删除只能使用逻辑删除，即增加一个标记字段来记录该数据的删除状态。
你遇到了这样一个场景，你的某个字段需要添加唯一键约束，因此你可能想了个办法，用业务来控制唯一键。例如你的数据表中name 是唯一的，现在你需要插入一条name = a的记录：
然而你的服务运行了一段时间后你还是发现了数据库中存在 name = a且is_delete = 0的多条字段，大部分是由于以下原因：
你发现在业务层面这个问题似乎是无法避免的，于是你开始考虑从数据库层面避免该问题。你决定在name字段添加唯一键约束，但很快就否定了这个想法，因为这样根本没法进行删除，所以你开始在网上寻找解决办法并找到了这篇文章。
有没有解决这个问题的办法？
百度、谷歌帮帮我!
在网上搜寻很久以后，我看到了简书上一篇比较好的文章：《逻辑删除真的不是一个好的设计》。该文章提供了三个方法:
1.放弃mysql 2.添加delete_token字段 3.使用数据仓库，评论区机智网友还提出了方法2的改进: 方法2.5。
方法2，即为数据库添加新的一列delete_token，当某一条记录需要删除时，将该字段设置为一个UUID，将name、delete_token设置为唯一键，这样当is_delete=0时，delete_token保持一个默认值，能够有效地限制name唯一，当记录被删除时，由于delete_token是一个唯一的UUID，便能保证删除的记录不会被唯一约束束缚。但正如该文章的博主所说，UUID会占用很大的空间，所以不推荐使用。评论网友针对该问题提出优化对策：方法2.5：将删除记录的delete_token设置为该记录的id。
个人认为，索引太大只是其中一个弊端，该方法还会面临一个很棘手的问题：当需要批量删除时，需要对每一条记录进行逐行删除。例如该表还有一个字段叫age，现在需要删除age > 18的记录，共有50条，在业务中，由于需要为每条的delete_token字段插入一个UUID所以需要将其拆分为50条更新操作来进行。这样的代价显然很难接受
我该怎么办？
每种办法都有一定的应用场景，既然强制要求使用逻辑删除，就会面临很多问题，在所难免。今天刚好突然想到一个不错的点子能解决逻辑删除带来的问题，若该方法已经被提出，纯属巧合。
将删除标记设置默认值(例如0)，将唯一字段与删除标记添加唯一键约束。当某一记录需要删除时，将删除标记置为NULL。
由于NULL不会和其他字段有组合唯一键的效果，所以当记录被删除时(删除标记被置为NULL时)，解除了唯一键的约束。此外该方法能很好地解决批量删除的问题(只要置为NULL就完事了)，消耗的空间也并不多(1位 + 联合索引)。
目前还没发现这个办法有什么奇怪的bug。如果有请不要吝啬在评论区留言讨论。