Question

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

然而，假设与客户相关的其他可选数据的数量增加，并且仅仅为了论证，表的数量现在为10.最好使用相同的体系结构，以便有10个额外的列在customer表中，如果没有存储额外的数据，那么所有可能都为null，或者让FK指向来自子项的customer表更好？这个模型似乎更整洁，因为我没有大量的可空列，如果需要，我可以逐步扩展系统，只需在新表中添加新表和指向客户的新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)
);

就像一对多，'many'有一个'one'的外键，但要把'many'变成'one'，只需将它变为unique。通过使依赖关系上的外键列成为该关系的主键，表达所有这些通常很方便：

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

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

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

从严格抽象或学术角度来看，添加表格并不构成任何坏事;既没有添加属性。选择应始终基于您实际需要建模的数据类型。

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

确定哪些基本上需要实际数据，并对这些（可能是其他）配置进行性能测试，以确定哪种方法效果最佳。

Answer 2

部分答案：

请记住，以1-1或1-0..1的关系将表分成两个，总是需要在这些表之间进行额外的连接。

如果您经常需要将两个表中的数据一起返回，并且这些表负载很重，那么在较大的单个表中“大量的NULL值”会表现得更好。

1到0..1关系 - FK指向哪种方式？

2 个答案: