看完这篇文章后： http: //diovo.com/2008/08/are-foreign-keys-really-necessary-in-a-database-design/
在设计数据库时使用外键似乎是个好主意。但是你什么时候用的太多了？
例如，假设我有一个主表，用于存储其他程序通过以下列引用的机械零件信息列表：
我是否应该制作包含所有可能颜色、单位和类别列表的表格，然后将它们设置为机器零件信息表中相应列的外键？在什么时候使用外键的好处会超过我制作所有这些额外的表和关系的事实？
您希望能够确定地声明数据库中仅存在已知的有效值的任何属性都应使用外键进行保护。否则，您只能希望在应用程序代码和将来创建的任何接口中捕获无效值。
拥有更多的表和关系并不是一件坏事。唯一的问题——通常不是一个问题——与维护用于执行这些关系的索引的开销有关。在您遇到性能问题之前，您应该为“应该”拥有的每一列创建外键关系（因为需要根据列表验证值）。
在我愿意为性能牺牲正确性之前，性能考虑必须非常可怕。
每个设计都是竞争目标的妥协，因此很少有简单的答案（除了错误的答案）。
我当然会在他们自己的关键表中放入离散的度量，例如名称、颜色、类别、度量单位等。可变度量（成本、单位数量等）没有那么多，除非您有标准尺寸包装中的单位（即只有 1、6、12 等。）
设计数据库最简单的方法是从需求开始。在一种经典方法中，需求被总结在 ER（实体关系）模型中。在这个模型中，实体之间的关系不是发明的，而是被发现的。如果它们位于数据库应该涵盖的信息范围内，那么它们就是模型的一部分。时期。
从那里开始，当您转向数据库设计时，您已经知道您需要什么关系。您需要对表的结构做出一些决定，但几乎所有引用主键的外键都是需求的直接结果。
当然，如果您可以在设计过程中随意更改需求，那么您可以做任何您想做的事情。
维度建模很好地涵盖了您问题的所有要点。有太多的外键关系会降低查询性能。Kimball 的 Group Reader 很好地介绍了维度设计以及如何将客户需求转换为模式。
http://en.wikipedia.org/wiki/Dimensional_modeling
要问的主要问题是“数据需要受到多大的约束？” 关于机器零件的颜色，我认为，不将 ciena 和 camomille 作为颜色选择符合每个人的最佳利益。所以，最好有一个查找表。