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

发布于 2024-12-09 14:47:26 字数 382 浏览 0 评论 0原文

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

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

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

陌路终见情 2024-12-16 14:47:26

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

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

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

在 SQL 中：

CREATE TABLE independent (
    id INTEGER PRIMARY KEY
);

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

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

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

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

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

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

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

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

The answer is mechanically derived from the idea of functional dependence.

For a value to exist in one relation, it implies that a value must exist in the other. When this is true, there will be a foreign key constraint from the dependent table (the former) to the independent table (the latter)

Another way of looking at this is that a one to one relationship is actually just a special case of a one to many relationship; only instead of many, you are only allowed one.

in SQL:

CREATE TABLE independent (
    id INTEGER PRIMARY KEY
);

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

Like a one to many, the 'many' has a foreign key to the 'one', but to turn the 'many' into a 'one', just make it unique. It's typically convenient to express all of this by making the foreign key column on the dependent relation the primary key for that relation:

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

Edit: I noticed your title asks a different question than your body seems to ask. The above answers the title.

From the point of view of database normalization, it's probably preferred to use multiple tables, as above, in favor of nullable attributes. Nulls are sort of an out of band way of saying that the value of a particular attribute is in some way 'special', but doesn't really enforce any particular interpretation of what that might mean. A null manager_id probably means something totally different from a null birthdate, even though they have the same mark.

Adding tables isn't considered in any way a bad thing, from a strictly abstract or academic point; neither is adding attributes. The choice should always be based on what kind of data you actually need to model.

That said, there are some very real practical reasons to use one or the other. The most obvious performance reason comes from the space cost of using one or the other. When an optional value is usually used, the extra space used by the foreign key and corresponding index doesn't pay for itself to well. Similarly, if an optional value is rarely used; it's more compact to put those values in another relation. Having a nullable attribute would consume space in the table that is hardly ever used.

Figuring out which basically requires actual data, and performance testing these (and maybe other) configurations to see which works best.

回复收藏 0 原文