Oracle闲谈数据库级联删除与私删除的设计方案

背景:

当时半龙看了重了产设计模式和数据结构,又补了下基础知识,然后就失眠了一整夜,不知为甚就悟出级联及伪删数据是题目。

是因为级联删除是几乎人人都见面遇到的问题,但方案也鲜也无美好,所以欢迎大家集思文益,以下内容欢迎大家同谈谈。

级联删除的法子:

方式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:你与过的品类,现在是故啊方案为?觉的方案来改善之空间?

相关文章