Sql 关于1:1关系的困惑

我一直在学习数据库设计，对1:1的关系感到困惑。据我所知，您可以简单地将列添加到适当的表中。有人能提供一个现实世界的例子，说明1:1的关系是必要的，还是提供了一些显著的好处？也就是说，我应该在哪里使用1:1的关系，它看起来是什么样子？

如果X与Y有1:1的关系，Z与Y也有1:1的关系，这是很有用的。Y可以抽象到一个共享表中，而不是在X和Z中重复

编辑：一个真实的例子是客户、公司和地址。客户和公司之间可能存在N:N关系。但客户和公司都与地址有1:1的关系。某些地址行可能与客户和个人都相关

真正的一对一关系很少发生 发生在现实世界中。这种 建立关系通常是为了获得 围绕数据库的某些限制 管理软件，而不是 模拟真实世界的情况。在里面 Microsoft Access，一对一 在一个公司里，关系可能是必要的 当您必须拆分数据库时 表转换为两个或多个表，因为 安全或性能问题，或 由于255列的限制 每张桌子。例如，您可以保留 大多数患者信息 TBLPAINT，但请特别注意 敏感信息（如患者信息） 姓名、社会保险号码和 地址）在tblConfidential中（参见 图3）。获取信息 在tblConfidential中可能会更多 比TBLPaient更受限制。作为一个 第二个例子，也许你需要 只转移一大部分 表中的其他应用程序 定期的。你可以把桌子分开 转入转入和转入 非转移件，并连接它们 一对一的关系

这是一段引自

这是一个很好的例子

---

我可以看到使用1:1的另一个原因（我在过去使用过它）是，如果一个表有很多列，并且只有少数列涉及到非常密集和频繁的查询，需要快速，我会将它分成两个相关的表，它们是1:1，我可以查询轻量级表并获得良好的性能，但是通过一个简单的连接，仍然可以轻松获得与之相关的其他数据。

我将给您一个实际的示例

在医疗账单世界中，希望通过医疗保险获得报酬的医生通过为患者每次就诊创建口述报告来处理账单。这实际上可能是秘书转录的录音口述，但更多的时候，这只是他们与患者所做所谈的事情的书面描述，以及历史、印象等。然后，持证医疗编码员将阅读此口述，并决定允许医生支付的费用

除了口述之外，还有有关患者的人口统计信息：姓名、年龄、账单地址等。这些信息必须与口述信息严格分开，以防止编码人员允许偏见影响他们的账单判断或侵犯患者隐私

这些数据通常在原点的数据系统中以1:many关系保持良好的规范化，并且只有正确的部分在正确的时间显示给正确的人。然而，相当多的办公室将其计费功能外包给第三方。例如，这样一来，一家小型诊所就不必在员工中保留一名持有执照的医疗编码员；计费办公室的一名编码员可以处理许多诊所的需求。当数据从诊所发送到计费办公室时，患者人口统计信息和口述需要作为单独的部分，可能在不同的时间提交。此时，它们很可能存储在完全独立的表中，具有1:1关系和共享ID字段，以便以后匹配

在这种情况下，1:1关系与数据模型关系不大。您可能会在导入时匹配记录，随着账单在系统中的移动，诊所人口统计记录中接收到的省级患者信息最终将与真实的人匹配，以便恢复1:many关系。否则，你每次去看医生都会得到一份单独的账单

---

相反，它几乎与系统设计有关。在我们想象的计费服务中，可能有完全不同的人在构建和使用计费部分，而不是编码部分。这样，每一方都可以完全控制自己的领地，你可以确定没有人，甚至是开发者，正在违反任何隐私规则。

我的信念表应该以域背景设计。因此，如果这些列构成两个不同的实体，则不应将它们混合在一个表中。根据我的经验，随着时间的推移，1:1的关系往往会演变成1:n的关系

例如，您可能希望存储一个人的邮政地址。但过了一段时间后，您需要为每个人存储多个地址。将程序从1:1关系重构为1:n通常比从旧表中提取一些列到新表要容易得多

---

许多数据库系统允许以非常简单的方式定义每个表的访问权限。但是在单个列上定义权限通常非常痛苦。

1:1关系是一个抽象概念，您可以在数据中建模，但在数据库级别（假设RDBMS）并不存在。在一个表上总是有一个外键指向另一个表，因此从技术上讲，FK指向的父表可能有多个子表。这是您希望在业务逻辑中强制执行的内容

在建模意义上，1:1关系的一个好例子是员工和个人之间的关系。你有一个人有特定的数据，然后你有额外的属性