我正在为 Timesheet 应用程序设计一个 oracle 数据库。我想知道是否真的有必要对表（Master 和 Child）进行外键约束。
正如我们所知，理论上在表上具有适当的参照完整性是件好事，但我们真的需要它们吗？
我听说外键使数据库在每个 DML 操作上额外工作，因为它必须检查 FK 一致性。这会降低性能。但另一方面，在在子表中插入新行之前已删除主键的情况下，它可能会有所帮助。
性能是时间表应用程序中的一个主要问题，在月底（可能同时）将有大约 250 人填写他们的时间表。
如果我在表上没有外键约束，那么每次在子表中插入新记录之前，如果主表中存在主键，我是否必须先检查它（在存储过程中）？
补充：过去，我曾与许多经验丰富的 oracle 数据库开发人员一起工作，我们从未在表上使用过外键约束。
我会说开发具有适当外键约束的应用程序，然后测量性能，如果性能是一个问题，测量带有 FK 约束和没有 FK 约束的 DB 之间的差异，如果它们被证明是一个性能问题，请考虑消除他们。
您不太可能发现它们是任何性能问题的根源，我不建议从一开始就完全忽略它们，因为猜测它会带来更好的性能。
您不需要它们，就像您不需要验证输入、佩戴安全带等一样。
任何确保强制执行外键的方法（例如在 sp 或 trigger 中）都将至少与引用约束一样慢（预计它会慢得多）。唯一更快的可能性是确保您的应用程序没有任何错误并且不会创建丢失的引用。由于某些原因，这太难了：
考虑以下场景：表 A 有一个引用表 B 的列，一个用户在 B 中插入一行，在任何人在 A 中使用它之前，决定删除它......同时，另一个用户已经打开了插入表单A 有一个由 B 行填充的组合框。当他保存此 A 时，它可以引用错误的 B，我认为没有自然架构可以防止这种情况发生，这可能比关系本身更快。
我可以继续提供尽可能多的示例，但简而言之，我在应用程序架构方面的经验表明，尽可能多地保留模式级别的约束，并有更多时间与家人共度！
除了其他人关于数据一致性和查询性能的说法......
在数据库中拥有外键也是文档——您无需翻阅代码库即可了解表应该如何关联。随着数据库中表数量的增加或访问该数据的应用程序数量的增加（或者您无权访问代码并且您仍然需要理解数据），这一点变得更加重要。
我的 2 美分……250 个人没什么好担心的。数据库可以处理大量数据和引用。这就是他们的目的。显然，在创建键和结构时要动动脑筋。但是您将获得准确的数据和适当的密钥，而不是可能的噩梦来构建报告等等......最后......这就是你描述的应用程序的重点，简化和协助数据输入并加强数据准确性。