是否有一个答案矩阵我可以用来决定我是否需要外键？

Question

例如，我有一个存储类的表，以及一个存储class_attributes的表。 class_attributes有class_attribute_id和class_id，而classes有class_id。

我猜如果数据集是“独生子女”或“仅属于”或“完全归属于”，那么我需要一个FK来识别父母。如果没有class_attributes表中的class_id，我就永远无法知道这个属性属于哪个类。

也许有一个有用的答案矩阵？

Answer 1

我没有答案矩阵，但为了澄清，我们讨论的是数据库规范化：

http://en.wikipedia.org/wiki/Database_normalization

并且在某种程度上非规范化：

http://en.wikipedia.org/wiki/Denormalization

Answer 2

Wikipedia很有帮助。

  

在关系的背景下   数据库，外键是一个   两者之间的参照约束   tables。1外键标识   一列中的列或一组列   （引用）引用a的表   另一列中的列或列集   （参考）表。中的列   引用表必须是主要的   密钥或其他候选密钥   参考表。

（并且它会越来越详细）

如果要强制执行约束，即class_attributes中的每一行仅适用于一行类，则需要外键。如果您不关心强制执行此操作（即，您可以为不存在的类创建属性），则不需要FK。

Answer 3

我会说，这是相反的方式。首先，您需要设计需要的物体。对于那些将创建一个表。

此阶段的一部分是设计密钥，即唯一标识对象的属性（列）组合。出于方便或性能原因，您可能会或可能不会添加人工密钥或代理密钥。从这些密钥中，您通常会选择一个规范密钥，主密钥，您尝试一致地使用该密钥来识别该表中的对象（您还保留其他密钥，它们用于确保作为业务规则的单一性，而不是用于识别目的。）

然后，您认为对象之间存在什么关系。由另一个对象“拥有”的对象或引用另一个对象的对象需要某种方式来标识其相关对象。在相应的表（子表）中，添加列以使外键指向引用表的主键。

这可以处理所有一对多的关系。

有时，对象可以多次与另一个对象相关联。例如，订单可用于订购多个产品，但产品也可以出现在多个订单上。对于这些关系，您可以设计一个单独的表（交集表 - 在此示例中为order_items）。此表将具有从两个外键创建的唯一键：一个指向一个父键（订单），一个指向另一个父键（产品）。再次，您将列添加到交叉表中，您需要创建这些外键。

简而言之，您首先设计密钥和外键，然后才开始添加列来实现它们。

Answer 4

不要关心关系的类型 - 它更多地与关系的基数有关。

如果您有一对多的关系，那么您需要为较小的表分配主键，并将其作为外键存储在较大的表中。

你也可以通过一对一的关系来做到这一点，但是有些人认为你应该避免它们。

在多对多关系的情况下，您需要创建一个连接表，然后让每个原始表都有一个连接表的外键。