sql - 添加外键关系危险吗？

Question

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

Answer 1

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

更大的系统是您可以看到更多的“程序”和更少的“自动化”（即级联删除）。对于较大的设置 - DBA-s 通常更喜欢在数据库维护阶段处理它。很多时候，不允许通过中间件应用程序代码删除记录——而只是简单地标记为“已删除”或不活动——并稍后根据组织中的数据库例程和程序（存档等）进行处理.

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

So, I wouldn't lose my sleep over that. 使用“太多”的参照完整性约束（性能、维护）还有其他问题——但这在 DBA-s（以及一般的 Db 专业人士）之间通常是一个非常有争议的问题，所以我不会深入探讨:)

Answer 2

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

Answer 3

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

Answer 4

你不应该从一开始就设计一个没有外键的关系数据库。这是随着时间推移数据完整性较差的保证。

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

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

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

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