删除外键约束,参照完整性和Hibernate

Suj*_*jee 3 oracle referential-integrity hibernate

我的同事提到我们的客户DBA建议删除项目Oracle DB模式中的所有外键约束.最初我不同意这个决定.我是开发人员而不是DBA.后来才意识到这个决定背后可能有一些原因.所以我正在尝试获得这个决定的利弊.

项目信息:

  1. Spring应用程序与Hibernate持久化.
  2. Oracle 10g DB
  3. 批处理作业仅使用SQL-loader或普通JDBC.

这是我的利弊清单(如果我错了请纠正我)

优点:

  1. 由于应用程序持久性由Hibernate管理,因此不需要外键级联.它由Hibernate管理,具有适当的级联选项.

  2. Hibernate DELETE操作(包括删除级联选项)在删除主键记录之前删除外键表记录(即避免引用完整性问题).对于非外键的情况,外键情况和外键与级联情况,此行为相同.但是添加外键会不必要地减慢Oracle删除操作的速度.

缺点

  1. Hibernate提供了一种机制,用于管理对象之间的关联以及关联中的级联操作.但它永远不会提供DB拥有的完整的参照完整性解决方案.

  2. 这些批处理作业仅使用SQL-loader或普通JDBC需要参照完整性.

伙计们,我需要你的建议.如果你们中的任何人都是DBA,请提供DBA方面的原因.

谢谢.

Ton*_*ews 9

我之前从未听过DBA的这样的提议!来自应用程序开发人员,是的,但绝不是来自数据库管理员.它乞丐信仰.

Tom Kyte多次说过(例如这里):应用程序来去匆匆,但数据是永恒的.

根据我自己的经验,我已经研究了20多年前的Oracle数据库.他们从Oracle 6开始,多年来迁移到10G或11g - 相同的数据.但坐在上面的应用程序?首先它们是Forms 3.0,然后在某些情况下,它们被迁移到C++,有些已经在Forms 6i中重新构建,在Application Express中重建了一些.ADF当然是另一种可能性; 或者可能是SOA架构......

当前的应用程序开发工具有什么特别之处,它突然接管了Oracle作为DBMS的工作?

  • +1在应用程序层实现FK功能,当下一个新的闪亮工具/框架出现时,您将全面完成. (3认同)

Bil*_*win 6

我曾在决定放弃参照完整性约束的项目中处理数据库.

我们必须编写"QC脚本"来检测与每个表关系相关的孤立行(孤立行将被外键约束阻止).

然后,当他们(而不是)他们出现时,我们必须制定如何解决孤儿的政策.选择包括以下内容:

  • 删除孤立的行.
  • 存档孤立的行.
  • 将任何孤立的外键值更新为NULL.
  • 将任何孤立的外键值更新为父表中的某个现有值.
  • 与异常生活在一起.编写更多代码以从报告中排除孤儿.可能在所有表格上都有一组VIEW?

您可能希望与此数据库的利益相关者安排定期每周会议以查看QC脚本报告,并决定如何处理每个孤立行.

没有框架可以像在数据库中运行的约束那样可靠地强制引用完整性.只有数据库才能提供真正的原子变化并确保一致性.