数据库设计——应该避免一对一的关系吗？ [复制]答案

【问题标题】：Database Design - Should one-to-one relationships be avoided? [duplicate]数据库设计——应该避免一对一的关系吗？ [复制]
【发布时间】：2011-04-25 18:31:52
【问题描述】：

可能重复：
Is there ever a time where using a database 1:1 relationship makes sense?

为了简单起见，我将直接问一个问题：数据库设计中的一对一关系应该避免还是可以接受？

我知道这个“项目”的所有属性都可以托管在一个表中，但我觉得当我通过 ORM 将我的数据库设计转换为业务对象时，它会用不必要的属性使实体变得混乱。

通过 UI，希望这能画出更好的画面，我有一个包含所有必要属性的主窗体。我将有一个按钮，允许用户单击它，它会弹出一个新表单来附加额外的属性。与主窗体（实体）关联的条目不能超过 1 个，即它是 0..1 结束关系。

我们将不胜感激。

【问题讨论】：

请记住，在数据库外观（具有很好的拆分表）和查询复杂性（当您突然必须加入所有这些表时）之间需要权衡取舍
所有物品都会有所有属性吗？
另一点是，取决于您的 ORM - 您可以将单个表映射到多个实体。您可以使用 .NET Entity Framwork 4 做到这一点。最终结果 - 更好的数据库设计和更好的代码 OO。
复制：stackoverflow.com/questions/517417/…

标签： database database-design orm

【解决方案1】：

有两种情况可能有意义：

可能与主要实体相关联的可选属性块，这使其成为 1:[0-1] 关系。这也可用于在执行对象/关系映射时表示子类的字段。
当作为物理设计的一部分完成时，性能非规范化。如果很少需要额外的属性，可以将它们分流到一个单独的表中，如果需要可以加入该表。但是，如果您的数据库可以使用 covering index 或 materialized view 进行优化以创建频繁访问的数据子集的物理表示，则可能不需要此技术。

【讨论】：

【解决方案2】：

如果所有项目都具有所有属性，那么通常有一个表是有意义的。

如果某些项目只有一些属性，那么有多个表是有意义的。

为了提高 ORM 的效率，诸如惰性属性获取之类的东西可能会派上用场。问题是，它仍然相当罕见。除非您真的认为这会是一个问题，否则不要担心优化。顾名思义，过早的优化并不是一个有效的消磨时间的地方。

【讨论】：

【解决方案3】：

取决于应用要求

通常，我会说一对一的关系被建模为表中的列，但是在某些情况下这过于严格：

您的架构经常更改，应用程序可以自定义对象的属性
性能不是问题，您正在使用视图为抽象后端属性存储创建数据布局

我见过在垂直分片和索引要求很高的数据库中，1->1 关系被拆分到表中的表。

您可以拆分和抽象到最终得到类似于Entity-attribute-value structure .. 的东西，除非您的应用程序需要它，否则这并不总是您想要的（增加复杂性、性能）。正如 marc_s 所说，您希望尽可能避免这种情况。

【讨论】：

绝对避免使用 EAV - 在这里查看原因：simple-talk.com/sql/t-sql-programming/…
告诉 Magento ;) 我同意你的看法
根据我的经验，EAV 的唯一借口是当您需要一个运行时可修改的架构并且有一个偏执或阻挠的 DBA，除了安装脚本之外什么都不喜欢发出 DDL。如果你真的在考虑 EAV，为什么不把 SQL 抛到脑后，使用键值存储或其他东西呢？
@Jeffrey - 完全同意，只是在说明您可能会以 1:1-ing 漫步的道路
嘿。我已经养成了一种对反模式真正感到兴奋的倾向 ;-)

【解决方案4】：

不，1:1 的关系完全有意义。

想象一个实体可以选择拥有一个充满属性的存储桶 - 您的一些实体有这些属性，而另一些则没有。

您可以将所有这些属性作为列包含到您的实体表中 - 但在这种情况下，对于大量条目而言，许多列最终会为空。

或者：您可以将那些“可选”属性放入单独的表中，与基本实体表建立 1:1（或更确切地说：0:1）关系，并且只存储内容如果您的实体确实具有这些属性，则在其中。

决定是否将某些属性“外包”到单独的表中的主要标准是：

这涉及多少个属性？如果只是一两个 - 不要竭尽全力将它们放在单独的表格中。但如果你说的是 8、10、15，那就考虑一下
有多少基本实体可能具有这些可选属性？再说一遍：如果 95% 的实体总是具有所有这些属性，那么做这个额外的步骤是没有意义的。如果只有一半或更少的实体具有这些属性 -> 我肯定会考虑这样的表

【讨论】：

谢谢！我的想法更符合你的！非常感谢您的回复！
我知道这是一个老问题，但我有很多合法 1:1 关系的例子，其中大多数是唯一正确的解决方案：stackoverflow.com/questions/517417/…

【解决方案5】：

我会避免一对一。如果没有技术需求，那就没有意义了。您只是为数据库创建额外的连接以及要管理的额外表和索引。此外，仅仅因为您的表包含所有字段并不意味着您的对象必须这样做。

【讨论】：