没有外键的数据库设计

Question

在各个雇主工作之后,我注意到其中一些公司的"糟糕"数据库设计趋势- 主要是排除外键约束.它一直在告诉我这些交易系统没有FK,这将促进参照完整性.

• 交易系统中是否存在任何情况,即忽略FK是有益的？

• 有没有其他人经历过这个,如果是这样的结果是什么？

• 如果他们遇到这种情况并被要求维护/增强系统,应该怎么做？

Answer 1

我想不出任何情况,如果两列有依赖关系,它们不应该在它们之间设置FK约束.删除参照完整性可以肯定加快数据库的操作,但有一个非常高的支付该费用.

我也经历过这样的系统和通常的结果是损坏的数据,在记录存在不应该存在(反之亦然)的感觉.这些是人们认为他们没事的系统,因为应用程序会处理它,而不是关心:

• 每个应用程序都必须处理它,而不是一个数据库服务器.
• 它只需要一个bug或恶意应用程序就可以为每个人搞砸了.
• 数据库负责保护自己!这是它最好的功能之一.

至于你应该做什么,我只是提出了可能出错的事情,以及如何使用FK来防止这种情况(如果有必要,通常会对我的观点进行成本/收益分析"倾斜").然后让公司决定 - 毕竟这是他们的数据库.

Answer 2

有一种观点认为,编写良好的应用程序不需要参照完整性.如果应用程序做得对,那么思考就是,不需要约束.

这种想法类似于不进行防御性编程,因为如果你正确地编写代码,你就不会有bug.虽然如此,但根本不会发生.不使用适当的约束是要求数据损坏.

至于你应该做什么,你应该鼓励公司在每个机会都增加约束.你不想把它推到陷入困境或为自己做一个坏名声,但只要环境合适,继续推动它.从长远来看,每个人的生活都会更好.

Answer 3

就个人而言,我对没有明确声明外键的数据库没有任何问题.但是,这取决于数据库的使用方式.

我使用的大多数数据库都是从一个或多个事务系统派生的相对静态数据.我并不特别关注影响数据库的恶意更新,因此外键关系的明确定义并不是特别重要.

我所拥有的一件事是非常一致的命名.基本上,每个表有一个称为ID的第一列,即列如何精确其它表refered到(或,有时有一个前缀,当有两个实体之间的多个关系).我也试着坚持,在这样一个数据库中的每一列都有一个描述属性(所以"CustomerStartDate"是从"ProductStartDate"不同)的唯一名称.

如果我处理的数据更多的是"在锅中做饭",那么我想更明确一下外键关系.然后,我更愿意承担外键定义的开销.

这种开销出现在很多地方.在创建新表时,我可能想使用"create table as"或"select into"而不用担心约束的细节.在运行更新或插入查询时,我可能不希望数据库开销检查我知道的确定的事情.但是,我必须强调,一致的命名大大增加了我对事情没有问题的信心.

显然,我的观点不是DBA,而是实践者.但是,表格之间的无效关系是我 - 或者我团队的其他成员 - 几乎从不必处理.