事前做好安全措施还是事后补救？

经常会下面这种情况:
要从数据库删除一条记录，但由于外键关联无法删除（不能做级联删除）。这里有两种处理方式：事前检查，事后报告
事前检查：检查是否还有其他记录关联到待删除的记录
事后报告：如果抛出数据库异常，可以写一个通用的翻译工具类，通过解析异常代码和异常中是否包含外键约束名来报告不同的错误。
我觉得前者比麻烦，但比较合理，因为这种情况是可以预料的，不应该让它发生异常。后者比较简单，实际上我也用第二种办法。
我非常想听听大家的观点

都用过


用前一种是由于系统中 不真正的删除一条数据(每条信息都是有标志位的...备份时删除)

用后一种是防止删错

我也是采用第二种做法哦，我觉得第一种很麻烦，每次都要查询数据库，如果外键关联多了话，判断就更多了，操作数据库也比较频繁，会影响性能的。

我们一般都不设置主外键，再删除前检查。基本也是第一种！

毫无疑问,如果现实存在需要级联删除的情况,而系统没有针对这种情况作出设计,明显是设计不良.
duooluu 说的方法都不可取, 如果确实用户想删除数据,那么检查删除所有满足删除的必要条件是必须的,
如果可以删除,那么提醒用户有大量相关数据需要删除,如果不能删除,告诉用户需要把那些数据写删除才能删除,这才是一个有可用性的系统.
还有楼上有人说不要约束什么的更是不可取,我实在想不出什么理由要使用一个数据可能出现错误的系统.
至于性能问题,在数据正确性无法得到保障以前,要速度来干什么?

如果你的数据设置了外键约束，那么你在事前还是处理一下吧，为了系统健全在操作的时候也检查一下吧

你能举例说明一下你实际如何设计的么？


我在项目中采用第二种方式。
级联删除的情况一般适合于主项--明细数据，删除主项则级联删除明细；
对于公共的数据字典表，一般也不提供“告诉用户需要把那些数据写删除才能删除”的功能，当然提供会友好一些，不过第一比较复杂、第二性能有所降低（可能不是大问题），如果数据被引用而不能删除，一般采用禁用代替删除功能即可。

一个数据“出错”的系统很正常阿，不信可以在这里调查调查。

举个路人皆知的例子：
Java垃圾收集器就是一个“出错”的系统。当对象不再使用时，并没有马上把内存堆数据清除，而是到某个时候才进行清除。在还没有清除之前，就是一种“出错”状态，如果你认为这是出错。linux文件系统中也存在这种出错设计：你完全有可能locate到一个文件，但实际他已经被删除了。


大访问量系统，要以性能为考虑。有些数据允许暂时出错的，只要有固定的机制在一段时间内(比如几分钟或1天)，或某个事件发生时(如第一次显示)时纠错便可。要做到保证系统每个时刻都是一致，那需要牺牲很大cpu计算时间，对大访问量网站系统，这种做法不允许。


经常来javaeye就知道javaeye也是个“出错”的系统。

这个同意. 按照"敏捷"原则, 最好去提高团队解决各种异常情况的能力, 而不是去提高设计 "不出错" 系统的能力.


这个不同意, Java GC对应用层是透明的, 应用如果可以获得一个对象引用, 它就可以一直获得同一个对象, 不管获得的是先前已经被标为unreachable的实例, 还是新的实例; 而如果应用获得了一个新的实例, 它就再也不可能获得原来被标为unreachable的实例了.


这个例子可以同意, 不过应该说是locate索引机制的问题吧, 完全是文件系统实现之外的功能. 说是linux文件管理系统可能更恰当.

扯个跟主题远一点的, 在 TOB 这个面向对象的数据库里, 级联删除是通过应用持久类重载 killingNotify() throws ObjectDependedException; 实现的, 这样就根本没有Java套在SQL数据库上头产生的这种问题了, 应用可以通过抛出的 ObjectDependedException 很好的诠释删除失败原因.