数据库表级联删除的问题

Question

项目中遇到一个问题，我负责开发的模块与7张表有关，彼此有主外键关系，
但没有设置级联更新和级联删除。而我现在恰恰需要实现多张表之间的级联
删除功能，除了改动数据库有没有别的办法来实现？大家给些建议。改动数据
库表估计不大可能，我们的DBA一向不设置级联删除，不知道这是为什么，我
没发现这样有什么好处。

Answer 1

DBA 当然不会设置级联了，甚至连表的外键一般都不会设置的。建议不要使用 CASCADE，这个会把程序弄得很混乱，同意楼上的

Answer 2

主外键关系， 
但没有设置级联更新和级联删除。而我现在恰恰需要实现多张表之间的级联 
删除功能？
是否使用hibernate,如果用了就使用hibernate的级联删除啊，
如果不是，则只能两条sql完成啦
delete sub where main_id in (main_id )
delete main where main_id in

Answer 3

如果只有两层也就罢了，问题是一共7个表最多的药级联四层！
而且很遗憾我们没有使用hibenate,刚才跟DBA沟通过了他也不
同意用trigger和级联，让我自己写SQL，去维护这些表之间
的数据完整性，我要自己去实现数据库中已经提供的功能。

Answer 4

自己写了3个类:TableInfo、TableRelationCfg 、DataBaseUtil 将这个问题解决了。
在TableRelationCfg中手动配置表之间的关系便可实现级联删除.
这个重复的轮子造的是在是没有什么意义，但我对项目的架构和数据库设计都没有发言
权,我不能因为自己的这点不便去要求项目使用hibenate或者要求dba加trigger或设置级联
删除。唯一能做的只是按要求完成自己的任务.

Answer 5

一般为了约束性级联都不建的，
以前就是手动写SQL。很是麻烦的。
希望能有好的解决办法

Answer 6

楼主杯具  呵呵good luck

Answer 7

和缓存，lazy 并列 三大 Hibernate 类似的 ORM 工具 双刃剑。

Answer 8

一般都不设cascade或FK的，否则很容易把数据给误删了。
而且设置某些约束可能造成开发上的不方便，有的也会影响数据库插入或修改时的性能。
有些约束本来就是应该在操作数据库之前就校验好的，否则数据库压力太大也不是什么好事。
还是觉得用代码控制较好。

Answer 9

看来以上的所有回帖，发现这已经是一个“心照不宣”的开发规矩了，不设置级联。我们的项目中也是，不过我们是小公司，没有什么DBA，表都有我来操作，不过我也不设置级联，都是先删除关联再删主，就怕级联删除误删，那你将欲哭无泪啊！数据库设计时，建立外键还是一个好习惯的，像有一楼说的连外键都不设置，为了开发自由，我想有一天你遇到问题，你找错都找不到，就因为数据不完整。设计数据库起码要符合范式吧！

Answer 10

一一看了大家的回帖，几乎大家都不赞成使用级联删除.原因不外乎两种：
1.处于性能考虑
2.怕误删数据.性能这方面不做讨论因为本人不是DBA对数据库的知识仅限于写一些SQL
完成开发任务。至于怕误删数据，我觉得这一点是多少有些站不住脚的。
如果数据库设计的好的话怎么会误删呢？如果从数据库的结构上就不能
保证数据的完整性，那么多的水平各异的开发人员靠他们的自律就可以吗？
保证数据结构的完整性本来就是数据库系统应该负责也有能力负责的。
我觉得DBA不愿意给数据库做级联删除不排除有DBA想偷懒的成分，所以
他把工作分摊到了开发人员的头上，当然责任也随之转嫁了过去。
   但是我也要重申一点就是我虽然赞成使用级联删除但并不鼓励无限制的
滥用，毕竟一个大的系统表的个数是上百的，对这样大规模的数据做级联
删除的话确实是可怕的，造成误删的可能性确实很高。但是大的系统肯定是
分模块的，这些模块所涉及的数据是有一定的自治性的。到了模块这一层
表的个数就没那么多了，而且其复杂度也降下来了。对于这样小范围内的
数据做级联删除，我认为是完全可控的,也有必要做的。
   对于广大的开发人员来说，好多时候，数据库设计和架构都是没有太多
发言权的。设计上的一些很不起眼的地方很可能造成很大开发工作量。如果
在一个小的公司，项目进度比较紧，表的结构变来变去，为了维护数据的完整
性，他们的代码中这一部分也要变来变去，这个工作实在是很让人抓狂的。