在使用数据库时,是否有时候使用一对一关系是有意义的?

184

我最近在思考规范化问题,但我发现我无法想象出数据库中应该存在1:1关系的情况。

  • 姓名:社会安全号码(SSN)? 我会将它们放在同一个表中。
  • 人员ID:地址ID? 同样,放在同一个表中。

我可以举出无数个1:多或多:多(带有适当的中间表)的例子,但从未碰到过1:1的情况。

我是否漏掉了一些明显的东西?


当数据库像这样分离时,将其拆分成多个物理设备会更容易。 - Pacerier
还有一个后续问题,如果有意义的话,如何做到呢?可以参考这里和这里。我的问题是如何选择哪个表具有外键约束?我猜这取决于你要解决什么用例... - Nate Anderson
26个回答

8

如果您有太多的信息,1-1关系也是必要的。表中每个记录都有大小限制。有时,表会分成两个部分(主表中包含最常查询的信息),以便记录大小不会太大。如果表较窄,则数据库在查询时也更有效率。


7
在SQL中,除非表是只读的,否则不可能强制执行两个表之间在两侧都是必须的1:1关系(除非表是只读的)。对于大多数实际用途来说,“1:1”关系在SQL中真正意义上的含义是1:0|1。
无法支持引用约束中强制基数的能力是SQL的一个严重限制。 "可延迟"约束并不真正计算,因为它们只是一种表述该约束有时不被强制执行的方式。

6

这也是一种扩展已经在生产中的表格的方式,相比于“真正”的数据库更改,风险较小。在遗留系统中看到1:1关系通常是字段在初始设计之后添加的一个很好的指标。


为什么犹豫不决?您认为全新的表格与更改现有表格一样具有风险吗?请列出添加新表格时会出现的问题。我唯一能想到的是操作元数据的代码,例如SELECT * From USER_TABLES loop <something> end loop。 - Mark Brady
1
事情不是会出错,而是添加一个1:1表格需要的工作比添加一个额外字段要多。现在,新记录意味着更新两个表格而不仅仅是一个。删除一条记录?也需要两个查询。现在我们需要维护更多的代码而不是只改变它一次。 - J.T. Grimes
@Mark Brady,强类型数据集在添加几个数据库字段时可能很难管理。如果数据集中的TableAdapter有许多查询等内容,那么只需拖入新表格就更容易完成了。 - Stefan
@Stefan:没有级联插入。 - J.T. Grimes
@Boofus,嗯...有时候我们确实不得不用键盘并编写一些程序来赚钱。 ;) - Stefan
通过添加第二个表格来扩展的一个很好的理由,正如在这里建议的那样,是与现有对象的向后兼容性。如果您正在运行多个版本的代码(我们经常这样做),并且想要添加一个必需的字段而没有合理的默认值,并保持旧代码运行,则添加第二个表格通常是可行的方法。 - Software Engineer

5
大多数情况下,设计通常被认为是1:1的,直到有人问道“为什么不能是1:many?”这时就需要提前将概念分离。人和地址并不紧密绑定。很多人会有多个地址等等...
通常,两个独立的对象空间意味着其中一个或两个都可以成倍增加(x:many)。如果两个对象真正、真正地是1:1,甚至在哲学上也是如此,那么它更像是一种is-relationship(同一关系)。这两个“对象”实际上是一个整体对象的部分。

4
如果您正在使用流行的ORM之一处理数据,您可能希望将一个表拆分为多个表以匹配您的对象层次结构。

3
悲伤的原因。如果ORM无法处理对象模型和物理存储之间的分歧,那就太悲哀了。 - Mark Brady
实际上,如果我理解正确的话,这意味着在关系数据库中实现分类层次结构。这是一种完全合法和自然的一对一关系情况;没有什么“悲哀”的。 - Tripartio

4
我发现当我建立一对一的关系时,这完全是出于系统性原因,而不是关系原因。
例如,我发现将用户的保留方面放在一个表中,将用户可编辑字段放在另一个表中,可以更容易地逻辑编写有关这些字段权限的规则。
但是你是正确的,在理论上,一对一的关系是完全人为的,并且几乎是一种现象。然而,从逻辑上讲,它使得抽象数据库的程序和优化更容易。

现象:是任何科学感兴趣的事实或事件,可以被科学描述和/或解释。我认为你不是想使用那个词。 - Mark Brady
1
我确实想使用它,以其罕见的含义。通常现象用于描述离群值,尽管它的定义需要你纠正我帖子中的每个单词。 - DevelopingChris
@DevelopingChris我同意1:1面谈的现象。除学校理论外,几乎不存在真实世界中存在这种情况的情形。 - Michael Riley - AKA Gunny

3

在某些情况下只需要扩展信息。这种情况下,遗留应用程序和编程语言(如RPG)会将程序编译到表格中(所以如果表格发生更改,您必须重新编译程序)。此外,在需要考虑表格大小的情况下,附加文件也可能很有用。


2
我认为一对一关系的最好理由是数据库设计中的超类型子类型。基于这个模型,我创建了一个房地产 MLS 数据结构。它有五个不同的数据源:住宅、商业、多户、酒店和土地。
我创建了一个名为 property 的超类型,其中包含每个五个独立数据源共同的数据。这种设计方法可以实现非常快速的“简单”搜索跨越所有数据类型。
我创建了五个单独的子类型,分别存储五个数据源的独特数据元素。每个超类型记录与适当的子类型记录之间存在一对一关系。
如果客户想要进行详细搜索,他们必须选择一个超级-子类型,例如 PropertyResidential。

2

通常情况下,它更多的是一种物理而非逻辑结构。它通常用于垂直分割表格,以利用跨物理设备或其他查询优化与将不经常访问的数据或需要比同一对象上的其他属性更安全地保留的数据进行隔离。

唯一的逻辑考虑是规定1-1关系时,某些属性仅适用于某些实体。然而,在大多数情况下,通过实体提取有更好/更规范的方式来建模数据。


1
如果有明显的性能优势,您可以创建一对一关系表。您可以将很少使用的字段放入单独的表中。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接