1 到 0..1 关系 - FK 应该指向哪个方向？

Question

假设我有一个与另一个表具有 1:0..1 关系的客户表，我通常会在客户表中有一个指向另一个表的 Nullable FK。

然而，假设与客户相关的附加可选数据片段的数量增加，并且仅出于论证目的，表的数量现在为 10 个。是否最好使用相同的架构，以便客户中有 10 个附加列表，如果没有存储额外的数据，则全部可能为空，或者让 FK 指向子级的客户表更好吗？这个模型看起来更简洁，因为我没有大量可为空的列，并且如果需要，我可以通过简单地添加新表和指向新表中的客户的新 FK 列来逐渐扩展系统。唯一的缺点是（查看数据库）您可以添加更多行来打破 1:0-1 关系规则。但是，我的应用程序无论如何都不会插入额外的行。

第一种方法要求我为添加到系统中的每个新表在客户表的末尾添加一个新列。

在这种情况下哪种方法最好？

Answer 1

答案是从函数依赖的思想中机械地得出的。

对于一个值存在于一个关系中，就意味着另一个关系中也必须存在一个值。当这是真的时，从属表（前者）到独立表（后者）将存在外键约束

另一种看待这一问题的方式是，一对一关系实际上只是一对多关系的一个特例；只是你只被允许一个，而不是很多。

在 SQL 中：

CREATE TABLE independent (
    id INTEGER PRIMARY KEY
);

CREATE TABLE dependent (
    independent_id INTEGER UNIQUE NOT NULL FOREIGN KEY REFERENCES independent(id)
);

就像一对多一样，“多”有一个指向“一”的外键，但要将“多”变成“一”，只需 make it 即可unique。通过将依赖关系上的外键列作为该关系的主键来表达所有这些通常很方便：

CREATE TABLE dependent (
    independent_id INTEGER PRIMARY KEY FOREIGN KEY REFERENCES independent(id)
);

编辑：我注意到你的标题提出的问题与你的身体提出的问题不同。以上回答了标题。

从数据库规范化的角度来看，可能更愿意使用多个表（如上所述），以支持可为空的属性。空值是一种带外方式，表示特定属性的值在某种程度上是“特殊的”，但并没有真正强制执行对其可能含义的任何特定解释。nullmanager_id可能意味着与 null 完全不同的东西birthdate，即使它们具有相同的标记。

从严格的抽象或学术角度来看，添加表格无论如何都不被认为是一件坏事。添加属性也不是。选择应始终基于您实际需要建模的数据类型。

也就是说，使用其中之一有一些非常现实的实际原因。最明显的性能原因来自于使用其中一种的空间成本。当通常使用可选值时，外键和相应索引使用的额外空间并不能很好地收回成本。同样，如果很少使用可选值；将这些值放入另一个关系中会更紧凑。具有可为空的属性会消耗表中几乎从未使用过的空间。

找出哪个基本上需要实际数据，并对这些（可能还有其他）配置进行性能测试，看看哪个最有效。