use*_*379 17 foreign-key database-design constraint best-practices
不使用 FK 约束是我公司的不为人知的规则。FK 约束仅在设计 ERD 时使用，在创建表时不使用。
据我的前辈说，在实际操作中，当我们处理紧急问题时，这些都是非常耗时的障碍。他说，当我们需要立即使用 INSERT/UPDATE/DELETE 语句时，约束会阻止这些语句的执行，并且在保持约束的同时编写语句也很耗时。我什至听说许多其他公司也在这样做。
虽然我有点理解这些挣扎，但我不确定这是否是一个好方法，因为它与我对 DB 的理解完全相反。这家公司也是我的第一份工作，所以我不知道其他公司是如何处理的。
实际上，您对此有何看法？这有道理吗？有更好的方法吗？其他公司在这方面的表现如何？
更新：对于韩国公司来说，这似乎是一种很常见的方法。我问了几个在别的公司工作的前辈，他们大多都说都是这样。甚至其中一个人在一家金融公司工作！有趣的...
Mic*_*een 33
没有什么是免费的。有时没有东西也不是免费的。有和没有声明外键都会带来成本和收益。
外键 (FK) 的目的是确保此处的此列只能具有来自该列的值1。通过这种方式，我们可以确保我们只为实际存在的客户、我们实际生产和销售的产品捕获订单。很多人认为这是个好主意。
我们在 DBMS 中声明它们的原因是它可以负责执行它们。它永远不会允许任何违反规则的数据。此外，它永远不会让您摆脱执行规则所需的数据。通过将这项任务委托给机器，我们可以对数据的完整性充满信心，无论它的来源是什么，何时编写或通过哪个应用程序。当然，这需要付出代价。DBMS 必须始终检查每一行、每个查询是否遵循了规则。这需要时间和精力，这是服务器的负担。它还要求人类按照遵守规则的顺序提交 DML。不再狡猾地强迫订单，然后再追上管理员。哦，没有淘气的人，你必须先创建客户，
没有外键，我们可以更自由地做我们可以做的事情，以及我们可以做的事情的顺序。可以临时删除有问题的行以完成关键流程。当恐慌结束后，数据可以被修补。INSERT 通常会更快一些（随着时间的推移而增加），因为没有进行 FK 检查。可以根据需要从数据库中提取任意数据子集，而不必确保包含所有支持数据。等等。如果相关人员了解系统、仔细记录、有良好的和解程序、了解后果并有时间自己整理，这绝对没问题。代价是某处某处被遗漏一次，并且数据库恶化为几乎不可信的垃圾。
一些团队将检查放在应用程序中而不是数据库中。同样，这可以工作。然而，在我看来，使用这种方法的总服务器负载将大致相同（或略高），但忘记在某处检查一些代码的风险要高得多。使用 DRI，规则将一次传送到计算机，并永久执行。在应用程序代码中，每个新程序都必须重新编写。
对于我的两分钱，我完全支持外键。让计算机做他们擅长做的事情，比如例行重复检查列值是否匹配。我们人类可以专注于梦想新的和有趣的东西。几个月前负责一个系统后，我将 FK 添加到大多数表中。但是，有一些我不会添加它们。这些是我们从外部来源收集数据的地方。拒绝这些行的成本大于接受错误数据并在以后修复它的成本。因此，对于这几张表，将没有外键。我睁大眼睛做这件事，知道我们有监控和纠正程序。
1我承认多列外键约束的存在。