你的位置:首页 > ASP.net教程

[ASP.net教程]聊聊数据库级联删除与伪删除的设计方案


背景:

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

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

级联删除的方式:

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