假设我有一个与另一个表具有 1:0..1 关系的客户表，我通常会在客户表中有一个 Nullable FK 指向另一个表。
但是，假设与客户相关的额外可选数据的数量增加了，并且只是为了论证，表的数量现在是 10。最好使用相同的架构，以便有 10 个额外的列在客户表中，如果没有存储额外的数据，所有可能都为空，还是让 FK 从子表指向客户表更好？这个模型看起来更整洁，因为我没有大量可空列，如果需要，我可以通过简单地添加新表和指向新表中的客户的新 FK 列来逐步扩展系统。唯一的缺点是（查看数据库）您可以添加更多打破 1:0-1 关系规则的行。但是，无论如何，我的应用程序永远不会插入额外的行。
第一种方法要求我为添加到系统的每个新表在客户表的末尾添加一个新列。
在这种情况下哪种方法最好？
【问题讨论】：
标签： database-design database-normalization
答案是机械地从功能依赖的概念推导出来的。
如果一个值存在于一个关系中，则意味着一个值必须存在于另一个关系中。这样的话，从依赖表（前者）到独立表（后者）会有外键约束
另一种看待这个问题的方式是，一对一关系实际上只是一对多关系的一个特例；只有一个，而不是很多。
在 SQL 中：
CREATE TABLE independent (
id INTEGER PRIMARY KEY
);
CREATE TABLE dependent (
independent_id INTEGER UNIQUE NOT NULL FOREIGN KEY REFERENCES independent(id)
);
就像一对多一样，“多”有一个“一”的外键，但要将“多”变成“一”，只需将其设为unique。通过将依赖关系上的外键列作为该关系的主键来表达所有这些通常很方便：
CREATE TABLE dependent (
independent_id INTEGER PRIMARY KEY FOREIGN KEY REFERENCES independent(id)
);
编辑：我注意到您的标题提出的问题与您的身体似乎提出的问题不同。以上回答了标题。
从数据库规范化的角度来看，可能更喜欢使用多个表，如上所述，以支持可为空的属性。 Null 是一种带外方式，表示特定属性的值在某种程度上是“特殊的”，但并没有真正强制对这可能意味着什么进行任何特定的解释。空 manager_id 可能意味着与空 birthdate 完全不同的东西，即使它们具有相同的标记。
从严格的抽象或学术角度来看，添加表格绝不是一件坏事；也没有添加属性。选择应始终基于您实际需要建模的数据类型。
也就是说，使用其中一个或另一个有一些非常实际的原因。最明显的性能原因来自使用其中一种的空间成本。当通常使用可选值时，外键和相应索引使用的额外空间并不能很好地为自己付出代价。同样，如果很少使用可选值；将这些值放在另一个关系中会更紧凑。具有可为空的属性会占用表中几乎从未使用过的空间。
找出哪些基本上需要实际数据，并对这些（可能还有其他）配置进行性能测试，看看哪种效果最好。
【讨论】：
部分答案：
请记住，将具有 1-1 或 1-0..1 关系的表一分为二，将始终需要在这些表之间进行额外连接。
如果您经常需要同时从两个表返回数据，并且这些表负载很重，那么在较大的单个表中包含“大量 NULL 值”会更好。
【讨论】：