添加外键关系危险吗？

Question

我对数据库很陌生，所以请光临我。

作为程序员，添加对象的引用是相当安全的，但添加外键关系（我认为）是非常危险的。通过添加FK关系，必须更新从该外表中删除行的所有查询，以便在实际删除行之前正确删除与该行绑定的外键。如何搜索从此外表中删除行的所有查询？这些查询可能隐藏在代码和存储过程中。这是维护噩梦的真实例子吗？这个问题有解决方案吗？

Answer 1

你的陈述根本不是真的。建立外键关系时，可以将级联属性设置为cascade delete。完成后，删除父级时将删除子记录，确保没有孤立的记录。

Answer 2

如果你使用正确的ORM解决方案，正确配置FK和PK，并启用级联删除，你应该没有任何问题。

Answer 3

我不会这么说（以确认别人提到的内容） - 这通常是通过级联删除来处理的。提供您想要的方式 - 或者通过仔细的程序来清理背后的东西。

更大的系统是你可以看到更多的“程序”而不是“自动化”（即级联删除）。对于较大的设置 - DBA-s通常更愿意在数据库维护阶段处理它。通常，不允许通过中间件应用程序代码删除记录 - 但只是标记为“已删除”或非活动 - 稍后根据组织中的数据库例程和程序处理（存档等） 。

除非你有一个非常庞大的代码库，否则这不是一个大问题。此外，通常，大多数Db代码都经过一些可以轻松遍历的DAL层。或者您也可以查询系统表中的所有关系和“依赖关系”，并为这样的代码维护编写了许多例程（在“fence”的两侧）。并不是说它不是一个“问题”，只是与正常的Db工作没什么不同 - 而且事情比这更糟糕。

So, I wouldn't lose my sleep over that。围绕使用“过多”参照完整性约束（性能，维护）还存在其他问题 - 但这在DBA-s（以及一般的Db专业人员）中通常是一个非常有争议的问题，所以我不会深入研究：）

Answer 4

您不应该从一开始就设计没有外键的关系数据库。这是长期数据完整性不足的保证。

您可以像其他人建议的那样添加代码并使用级联删除，但这通常也是错误的答案。有些时候你真的希望删除因为你有子记录而停止了。例如，假设您有客户和订单。如果您删除了有订单的客户，那么您将丢失订单的财务记录，这是一场灾难。相反，您希望应用程序收到错误消息，说明该客户存在订单。进一步级联删除可能会突然让您删除数百万个子记录，从而在发生大量事务时锁定数据库。这种危险的做法很少（如果有的话）在生产数据库中使用。

添加FK（如果您有关系，则需要它），然后搜索从该表中删除的代码并进行适当调整。考虑软删除是不是更好的选择。这是您将记录标记为已删除或不活动的位置，因此它不再显示为数据输入选项，但您仍可以查看现有记录。您可能需要相当严格地调整数据库代码才能正确实现。对于拥有从一开始就设计糟糕的数据库没有简单的解决方法。

如果您认为您将拥有许多子记录并且确实想要删除它们，则软删除也是一个不错的选择。这样，您可以标记记录，使其不再显示在应用程序中，并使用在非高峰时段运行的作业批量删除记录。

如果要添加新表并添加FK，那么处理它肯定更容易，因为在编写任何代码之前你会创建表。