多少个外键才算太多？答案

【问题标题】：How many foreign keys is too many?多少个外键才算太多？
【发布时间】：2012-09-23 16:07:10
【问题描述】：

在设计数据库时使用外键似乎是个好主意。但是你什么时候用的太多了？

例如，假设我有一个主表，用于存储其他程序通过以下列引用的机械零件信息列表：

我是否应该制作包含所有可能颜色、单位和类别列表的表格，然后将它们设置为机器零件信息表中相应列的外键？在什么时候使用外键的好处会超过我创建所有这些额外的表和关系这一事实？

【问题讨论】：

取决于....可能是颜色，请记住人们可能会拼错，您可能想轻松搜索。可能不是单位，因为您可以只使用 int。大多数时候，任何适合“类别”的东西都可以放在另一个表中并做一个 FK 参考。这取决于。关系数据库设计和平面表/文件设计都有优点和缺点......它也可能取决于您使用的数据库，或者它周围的代码......只是做看起来很有意义的事情运行。
关系的一个好处是不会一遍又一遍地存储相同的数据...考虑不同数据类型的大小。对 varchar(max) 的数字引用将节省空间。但是，如果您正在使用 access 或者您的周围代码可以为您处理固定列表 - 也许颜色不是您想要单独表格的东西。
我认为让你进入“太多”核心的一个大问题是，你是否在这张表中做了很多插入？如果是，那么所有这些外键都需要根据它们的表进行检查，以确保它们是有效的。这不是免费的操作。不过，我猜像零件目录这样的东西不会有很多插入，而且它不会严重影响数据库的性能。
因此，如果我有另一个表只保存说......正在进行的项目和条目的记录不断被添加/删除，那么拥有外键是个坏主意吗？例如，用于级联删除的一些外键可以吗？
也许更深入地了解数据库规范化，尤其是第 3 范式会对您有所帮助 - 只需 Google 3NF。

【解决方案1】：

您希望能够确定地声明数据库中仅存在已知的有效值的任何属性都应使用外键进行保护。否则，您只能希望在应用程序代码和将来创建的任何接口中捕获无效值。

拥有更多的表和关系并不是一件坏事。唯一的问题——通常不是一个问题——与维护用于执行这些关系的索引的开销有关。在您遇到性能问题之前，您应该为“应该”具有的每一列创建外键关系（因为需要根据列表验证值）。

在我愿意为性能牺牲正确性之前，性能考虑必须非常可怕。

【讨论】：

请注意，FK 显然很有用，应该使用，但在数据验证方面，它们不是您唯一的选择。检查约束当然是有效的，并且应该在值谨慎、不根据业务逻辑进行更改并且没有与之关联的其他信息时使用。
确实如此。我希望不要混淆这个问题。 OP 引用的示例似乎都可以通过外键更好地处理。此外，根据我的经验，检查约束在数据库之间的可移植性稍差（尽管这可能并不重要，具体取决于您的开发环境）。

【解决方案2】：

每个设计都是相互竞争的目标的妥协，因此很少有简单的答案（错误的除外）。

我当然会在他们自己的关键表中放置离散的度量，例如名称、颜色、类别、度量单位等。可变度量（成本、单位数量等）没有那么多，除非您有标准尺寸包装中的单位（即只有 1、6、12 等）

【讨论】：

【解决方案3】：

设计数据库最简单的方法是从需求开始。在一种经典方法中，需求被总结在 ER（实体-关系）模型中。在这个模型中，实体之间的关系不是发明的，而是被发现的。如果它们位于数据库应该涵盖的信息范围内，那么它们就是模型的一部分。期间。

从那里开始，当您转向数据库设计时，您已经知道您需要什么关系。您需要对表的结构做出一些决定，但几乎所有引用主键的外键都是需求的直接结果。

当然，如果您在设计过程中可以随意更改需求，那么您可以做任何您想做的事情。

【讨论】：

【解决方案4】：

维度建模很好地涵盖了您问题的所有要点。有太多的外键关系会降低查询性能。 Kimball 的 Group Reader 很好地介绍了维度设计以及如何将客户需求转化为模式。

要问的主要问题是“数据需要受到多大的约束？”关于机器零件的颜色，我认为，不将 ciena 和 camomille 作为颜色选择符合每个人的最佳利益。因此，最好有一个查找表。

【讨论】：