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

背景：

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

因为级联删除是几乎人人都会遇到的问题，但方案却有限却不美好，因此欢迎大伙集思文益，如下内容欢迎大伙一块儿讨论。

级联删除的方式：

方式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：你参与过的项目，如今是用什么方案呢？觉的方案有改进的空间？