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

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/非规范化

Answer 2

维基百科很有帮助。

在关系数据库的上下文中，外键是两个表之间的引用约束。1外键标识一个（引用）表中的一列或一组列，它引用另一个（引用）表中的一列或一组列。引用表中的列必须是被引用表中的主键或其他候选键。

（它会越来越详细）

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

Answer 3

我会说，这是相反的方式。首先，你设计你需要什么样的对象。对于那些将创建一个表。

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

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

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

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

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

Answer 4

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

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

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

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