数据库设计 – 1到0..1关系 – FK指向哪种方式?

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

但是,假设与客户相关的其他可选数据的数量增加,并且仅仅为了论证,表的数量现在是10.最好使用相同的体系结构,以便客户中有10个额外的列table,如果没有存储额外的数据,那么所有可能都为null,或者让FK指向来自孩子的customer表更好?这个模型似乎更整洁,因为我没有大量的可空列,如果需要,我可以逐步扩展系统,只需在新表中添加新表和指向客户的新FK列.唯一的缺点是它出现(查看数据库)你可以添加更多行来打破1:0-1关系规则.但是,我的应用程序永远不会插入额外的行.

第一种方法要求我为每个添加到系统的新表在customer表的末尾添加一个新列.

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

最佳答案 答案是从功能依赖的概念中机械地得出的.

对于存在于一个关系中的值,它意味着一个值必须存在于另一个关系中.当这是真的时,从依赖表(前者)到独立表(后者)将有一个外键约束

另一种看待这种情况的方式是,一对一的关系实际上只是一对多关系的一个特例;只有少数人,你才被允许一个人.

在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’,只是让它独一无二.通过使依赖关系上的外键列成为该关系的主键,表达所有这些通常很方便:

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

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

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

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

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

弄清楚哪些基本上需要实际数据,并对这些(可能是其他)配置进行性能测试,以确定哪种配置最佳.

点赞