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

触发器删除及伪删除

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

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

标签：