聊聊数据库级联删除与伪删除的设计方案

背景：

这两天看了重温了下设计模式和数据结构，又补了下基础知识，然后就失眠了一整夜，不知为啥就想到级联及伪删数据这个问题。

由于级联删除是几乎人人都会遇到的问题，但方案却有限却不美好，所以欢迎大伙集思文益，以下内容欢迎大伙一起讨论。

级联删除的方式：

方式1：数据库设定级联：

常规MSSQL、MySql、Oracle都对设定了主外键关系的表提供级联删除。

优点：数据准确、使用方便，数据库设计之初就设定好。

缺点：

1：增加对增删改时外键检测的额外开销。

2：潜在危险系素大（如：删除部门或角色，发现一级联递归，整个系统的数据没了）。

3：不方便触发其它事件。

4：开发人员可能被屏蔽细节。

总体描述：适合小系统、小局部、无缓存状态的情况使用。

总体总结：很少使用。

方式2：触发器处理。

优点：DBA喜欢。

缺点：程序员不喜欢，很容易蒙B。

总体描述：适合系统负责人偏DBA爱好的场景，及业务无缓存场景。

总体总结：内部业务系统使用多、外部系统使用少。

方式3：业务代码控制

优点：程序员喜欢，自由控制度大。

缺点：程序员喜欢，自由控制度大（随着业务扩展，需要到处补代码）。

总体描述：爱自由，爱生活，爱写代码。

总体总结：常规方式，在所有系统使用都很广泛。

在方式3的基础上思考：如何在架构设计统一处理，减少代码的分布？

下面聊聊复杂度更高的伪删除问题：

触发器删除及伪删除

1：触发器方式

优点：

1：通过触发器删除，并将旧数据移到其它库或表。

2：数据干净，表压力小。

3：代码业务逻辑简单化。

4：DBA喜欢。

5：一手开发人员也喜欢。

缺点：

1：不好控制触发其它外部业务或事件（如在删的同时清文件等，但办法总比困难多）。

2：整体数据库压力大（这个还得看业务情况）。

3：级联的缓存不好控制（和写触发器的同步清楚业务还是可以控制）。

4：二接手维护的人员不喜欢。

总体描述：总体缺点不太明显，后期维护不便。

总体总结：业务系统用的相对较多。

2：伪删方式

优点：

1：数据只是标识状态，数据恢复容易。

2：开发人员喜欢。

缺点：

1：需要在系统各表增加版本号或IsDeleted等标识。

2：业务查询都需要增加过滤条件。

3：需要级联更新标识符号。

4：存在脏数据。

5：缓存需要全面控制。

总体描述：优点不太明显，缺点是业务代码分布复杂了。

总体总结：总体使用并不多。

扩展内容：

1：昨晚无意扫到了吉日一篇文章2010写的文章，大意是：

花一个星期增加伪删deletemark字段，改遍了所有业务代码。（评论主要偏触发器方案，及致人身攻击，6年过去了，相信那些人现在应该能淡定看问题了，地址就不贴了。）

2：对于增加字段带来的问题，有人说用视图处理。

3：另外看到一个有趣的场景：伪删后添加相同数据的问题。

增加IsDeleted字段后，把原来的【唯一键+IsDeleted】建立联合主键。

删除后：cyq 0。

新增加：cyq 1。

发现这时候就没法再删了，再删就两个cyq 0 冲突了，你会怎么解决？

在互联网上搜伪删除相关的内容并不多，可以预见该方案的使用并没有普及，原因可能也在于没有从架构上能统一处理的方案出现。

思考：如何在架构设计上统一处理，减少业务代码？

博客园的级联反应是？

假设博客园要删除或禁用一个用户，分析需要处理多少事情？

1：几乎系统所有表都要关联处理（文章，评论，点赞，积分，闪存，招聘，博客、知识库、收藏、新闻等....）

PS：文件、图片（考虑到文件或图片外部站大量有引用，不处理。）

2：若缓存需要时时失效（这几乎是导致整站式缓存瞬间失效，系统要崩了......好在园子目前缓存没有时效性要求。）

那么问题来了：

1：园子是全处理了，还只是局部处理呢？

全处理：工作量有点大，代码分布有点散，随着业务增加，还得补充逻辑代码。

不处理：到处留下的用户链接导致的404，会不会影响SEO呢？

2：用户在博问上被采纳的内容呢？删呢？还是不删呢？

3：园子目前是采用真删呢还是伪删呢？

 

总结：

1：以前都是自己静静思考完，把功能在V5框架里实现了再分享。

2：现在，分享问题，讨论后后，再确定总体思路。

3：你参与过的项目，现在是用什么方案呢？觉的方案有改进的空间？