去除外键约束、引用完整性和 Hibernate

Question

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

项目信息：

1. 具有 Hibernate 持久性的 Spring 应用程序。
2. Oracle 10g DB
3. 有些批处理作业仅使用 SQL 加载程序或普通 JDBC。

这是我的优点和缺点列表（如果我错了，请纠正我）

优点：

1. 由于应用程序持久性由 Hibernate 管理，因此不需要外键级联。它由 Hibernate 使用适当的级联选项进行管理。

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

缺点

1. Hibernate 提供了一种管理对象之间关联以及关联内级联操作的机制。但它从来没有提供 DB 那样完整的引用完整性解决方案。

2. 仅使用 SQL 加载程序或纯 JDBC 的批处理作业需要引用完整性。

伙计们，我需要你的建议。如果你们中有人是 DBA，请提供 DBA 的侧面原因。

谢谢。

Answer 1

我以前从未听过 DBA 提出这样的建议！是的，来自应用程序开发人员，但绝不会来自数据库管理员。这令人难以置信。

Tom Kyte已经说过很多次了（例如这里 )：应用程序来来去去，但数据是永恒的。

根据我自己的经验，我曾使用过已有 20 多年历史的 Oracle 数据库。他们从 Oracle 6 开始，多年来迁移到 10G 或 11g - 相同的数据。但是最上面的应用程序呢？首先它们是 Forms 3.0，然后在某些情况下迁移到 C++，有些在 Forms 6i 中重新构建，有些在 Application Express 中重新构建。当然，ADF 是另一种可能性；或者也许是 SOA 架构...

当前的应用程序开发工具有什么特别之处，以至于它突然取代了 Oracle 作为 DBMS 的工作？

Answer 2

我曾在决定放弃引用完整性约束的项目中从事数据库工作。

我们必须编写“QC 脚本”来检测每个表关系的孤立行（孤立行将被外键约束阻止）。

然后，当（而不是如果）它们发生时，我们必须制定如何解决孤儿问题的政策。选项包括以下内容：

• 删除孤立行。
• 归档孤立行。
• 将任何孤立外键值更新为 NULL。
• 将任何孤立外键值更新为父表中的某个现有值。
• 与异常共存。编写更多代码以从报告中排除孤儿。也许是所有表的一组视图？

您可能希望与该数据库的利益相关者安排每周一次的会议，以审查 QC 脚本报告，并决定如何处理每个孤立行。

没有任何框架能够像数据库中运行的约束那样可靠地强制执行引用完整性。只有数据库才能提供真正的原子更改并确保一致性。

Answer 3

由于数据库约束得到保证，因此在某些情况下，它们可以允许额外的优化。

例如，假设您有一个视图

CREATE VIEW orders_vw AS
SELECT ord.order_id, ord.customer_id, lin.product_id
FROM orders ord JOIN order_lines lin on ord.order_id = lin.order_id

，那么您有一个执行 SELECT Product_id FROMorders_vw WHERE order_id = :val 的查询
通过强制执行完整性，数据库知道 order_lines 中的任何 order_id 在父表中都有一行，并且由于实际上没有选择订单表中的任何值，因此它可以通过不访问订单表来节省工作量。
如果没有约束，数据库无法确定 order_lines 中的条目是否有父项，因此它必须执行访问订单表来检查它的额外工作。

根据您的查询模式，您可能会发现删除约束实际上会增加数据库的工作负载。

Answer 4

通常，数据库性能优化首先从去除外键开始。这是一种权衡：您在 DBMS 级别上出售有保证的完整性，并且必须自己管理它（这对于 Hibernate 来说相当容易，但要求在普通 SQL 中非常准确），并且由于查询中的外键检查，您可以获得更高的查询性能相当昂贵。