专栏名称: 数据分析与开发
伯乐在线旗下账号,分享数据库相关技术文章、教程和工具,另外还包括数据库相关的工作。偶尔也谈谈程序员人生 :)
目录
相关文章推荐
数据中心运维管理  ·  制冷原理入门必学知识 ·  5 天前  
数据中心运维管理  ·  数据中心日常运维解决方案 ·  5 天前  
数据中心运维管理  ·  数据中心日常运维工作中常用的节能措施 ·  6 天前  
51好读  ›  专栏  ›  数据分析与开发

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

数据分析与开发  · 公众号  · 数据库  · 2016-08-24 20:42

正文

(点击上方公众号,可快速关注)


来源:路过秋天

链接:www.cnblogs.com/cyq1162/archive/2016/07/25/5703060.html


背景


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


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


级联删除的方式


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



------------- 推荐 ------------


范品社推出的极客T恤,含程序员、电影、美剧和物理题材,面料舒适、100%纯棉,有黑、白、灰、藏青色,单件 ¥59.9、两件减¥12、四件减¥28、六件减¥42,详见网店商品页介绍。


(上面为部分 T 恤款式)


网店地址:https://fanpinshe.taobao.com


淘口令:复制以下红色内容,然后打开手淘即可购买


范品社,使用¥极客T恤¥抢先预览(长按复制整段文案,打开手机淘宝即可进入活动内容)