sql - 无外键的数据库设计

Question

在不同的雇主工作过之后，我注意到其中一些公司存在“糟糕”数据库设计的趋势 - 主要是排除外键约束。这些事务系统没有 FK，这一直困扰着我，而 FK 可以促进引用完整性。

• Are there any scenarios, in transactional systems, whereby the omission of FK's would be beneficial?

• Has anyone else experienced this, if so what was the outcome?

• What should one do if they're presented with this scenario and their asked to maintain/enhance the system?

Answer 1

我无法想到任何场景，如果两列具有依赖关系，则它们之间不应该设置 FK 约束。删除引用完整性可能肯定会加快数据库操作速度，但为此要付出相当高的成本。

我曾经经历过这样的系统，通常的结果是数据损坏，即存在不应该存在的记录(反之亦然)。人们认为这些系统没问题，因为应用程序会处理它，而不关心它:

• 每个应用程序都必须处理它，而不是一台数据库服务器。
• 只需要一个错误或恶意应用程序就能给所有人带来麻烦。
• 数据库有责任保护自身!这是其最佳功能之一。

至于你应该做什么，我只是提出了可能出现问题的情况以及如何使用 FK 来防止这种情况发生(如果有必要，通常会进行成本/ yield 分析，“偏向”我的观点)。然后让公司决定 - 毕竟这是他们的数据库。