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