为什么要创建外键约束？ [关闭]答案

【问题标题】：Why should i create foreign key constraint? [closed]为什么要创建外键约束？ [关闭]
【发布时间】：2012-07-02 20:39:09
【问题描述】：

我正在为 Timesheet 应用程序设计一个 oracle 数据库。我想知道是否真的有必要对表（Master 和 Child）进行外键约束。

我们知道理论上对表有适当的参照完整性是件好事，但我们真的需要它们吗？

我听说外键使数据库在每个 DML 操作上都额外工作，因为它必须检查 FK 一致性。这会降低性能。但另一方面，在子表中插入新行之前已删除主键的情况下，它可能会有所帮助。

性能是时间表应用程序中的一个主要问题，月底将有大约 250 人填写他们的时间表（可能同时）。

如果我对表没有外键约束，那么每次在子表中插入新记录之前，我是否必须先检查它（在存储过程中）是否主表中存在主键？

补充：过去，我曾与许多经验丰富的 oracle 数据库开发人员合作，我们从未在表上使用过外键约束。

【问题讨论】：

【解决方案1】：

我会说开发应用程序设置外键约束，然后测量性能，如果性能是一个问题，测量有 FK 约束和没有 FK 约束的 DB 之间的区别，如果它们被证明是一个性能问题，考虑消除它们。

您不太可能会发现它们是任何性能问题的根源，我不建议从一开始就完全忽略它们，因为这样会带来更好的性能。

您不需要它们，就像您不需要验证输入、佩戴安全带等一样。

【讨论】：

+1 加：仅仅因为一点点性能，我会永远牺牲我的引用完整性 - 尤其是不在生产中！
如果我在表上没有外键约束，那么我必须先检查它（在存储过程中）是否主表中存在主键，然后再在子表中插入新记录每次表？它不会减慢 DML 操作，因为我每次插入新记录时都会查询主（用于 PK 存在）表？
通过像您说的那样运行查询（在每次插入或更新和删除之前），您正在对该键字段进行某种形式的验证，从而强制键的引用完整性。至于性能，我认为你最好的选择......运行测试，看看是什么？ ://
@user1263981 - 在每次插入子表之前对主表运行查询几乎肯定会比实现外键更差性能，因为结果必须被返回给应用程序 - 为了安全起见，事务必须为该调用和插入保持打开状态。显然，如果您不知道子行属于哪个主行，则必须查询主表以识别它，但无论是否使用 FK，都是如此。

【解决方案2】：

在引用完整性的情况下，插入或更新键列时性能会受到轻微影响。然而，这几乎总是得到 p> 的补偿

1) 可靠且一致的数据

说真的，如果您不强制执行参照完整性，您究竟为什么要使用参照数据库？

【讨论】：

【解决方案3】：

任何确保外键被强制执行的方法（例如在 sp 或 trigger 中），将至少与引用约束一样慢（预计它会慢得多）。唯一更快的可能性是确保您的应用程序没有任何错误并且不会创建丢失的引用。由于某些原因，这太难了：

考虑以下场景：表 A 有一个引用表 B 的列，一个用户在 B 中插入一行，在 A 中的任何人使用它之前，决定删除它...同时，另一个用户已经打开了A 的插入表单，其组合框填充了 B 的行。当他保存此 A 时，它可以引用错误的 B，我认为没有自然的架构可以防止这种情况发生，这可能比关系本身更快。

我可以继续提供尽可能多的示例，但简而言之，我在应用程序架构方面的经验表明，尽可能多地保留架构级别的约束，并有更多时间与家人共度！

【讨论】：

【解决方案4】：

除了其他人所说的关于数据一致性和查询性能...

在数据库中拥有外键也是文档——您无需翻阅代码库即可了解表之间的关系。随着数据库中表数量的增加或访问该数据的应用程序数量的增加（或者您无权访问代码并且您仍然需要理解数据），这一点变得更加重要。

【讨论】：

【解决方案5】：

我的 2 美分... 250人没什么好担心的。数据库可以处理大量数据和引用。这就是他们的目的。显然，在创建键和结构时要动动脑筋。但是您将获得准确的数据和适当的密钥，而不是可能的噩梦来构建报告等等......最后......这就是你描述的应用程序的重点，简化和协助数据输入并确保数据准确性。

【讨论】：