数据库设计 - 应该避免一对一的关系吗？

Question

可能重复:
有没有时间使用数据库1:1关系有意义？

为了简单起见,我会直截了当地提出这个问题:是否应该避免数据库设计中的一对一关系或这是否可接受？

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

通过用户界面,希望这将描绘出更好的画面,我有一个主要形式,具有所有必要的属性.我将有一个允许用户点击它的按钮,它将显示一个新表单以附加额外的属性.不超过1个条目可以与主表单(实体)相关联,即它是0..1结束关系.

任何建议将被认真考虑.

Answer 1

不,1:1的关系完全有道理.

想象一下,一个实体可选地拥有一个充满属性的存储桶 - 您的某些实体拥有这些属性,而其他实体则没有.

您可以将所有这些属性作为列包含在实体表中 - 但在这种情况下,对于大量条目,许多列将为空.

或者:您可以将这些"可选"属性放入一个单独的表中,与基本实体表建立1:1(或更确切地说:0:1)的关系,并且如果您的实体真的有那些,那么只存储那里的东西属性.

决定是否将某些属性"外包"到一个单独的表中的主要标准是:

这涉及多少属性？如果它只是一两个 - 不要花时间将它们放在单独的表中.但如果你在谈论8,10,15 - 那就考虑一下吧
有多少基础实体可能具有这些可选属性？再说一次:如果95%的所有实体总是拥有所有这些属性,那么做这个额外的步骤是没有意义的.如果只有一半或更少的实体具有这些属性 - >我肯定会考虑这样一个表

谢谢!我的想法更符合你的想法!非常感谢您的回复! (2认同)
我知道这是一个老问题,但我有很多合法的1:1关系的例子,对于大多数关系来说,它们是唯一正确的解决方案:http://stackoverflow.com/questions/517417/is-there-ever-a -time-其中-使用-A-数据库-11-关系-使得义/ 28313151#28313151 (2认同)

Answer 2

我会避免一对一.如果没有技术需求,就没有意义.您只是为db和额外的表和索引创建额外的连接以进行管理.另外,仅仅因为您的表具有所有字段并不意味着您的对象必须.

Answer 3

取决于应用要求

通常情况下,我会说一对一的关系被建模为表中的列,但是这种情况下限制性太强:

我见过表格,其中1-> 1关系在垂直分片中的表格和具有较高索引要求的数据库中分开.

你可以分割和抽象到你最终得到的实体 - 属性 - 值结构的东西 ......这并不总是你想要的(增加了复杂性,性能),除非你的应用程序需要它.正如marc_s所说,你想尽可能避免这种情况.

根据我的经验,EAV的唯一借口是当你需要一个运行时可修改的模式*和*有一个偏执或阻碍DBA,除了发布DDL的安装脚本之外什么都不喜欢.如果你真的在考虑使用EAV,为什么不把SQL扔到船上并使用键值商店呢？ (3认同)
@Jeffrey - 不能同意,只是说明你可能会以1:1的方式徘徊的道路 (2认同)

Answer 4

有两种情况可能有意义:

可以与主要实体关联的一大块可选属性,这使得它成为1:[0-1]关系.这也可以用于在执行对象/关系映射时表示子类的字段.
一个性能的非正规化,当作为物理设计的一部分进行.如果很少需要其他属性,可以将它们分流到一个单独的表中,如果需要可以将其加入.但是,如果您的数据库可以使用覆盖索引或物化视图进行优化来创建频繁访问的数据子集的物理表示,则可能不需要此技术.