我很难弄清楚何时在数据库设计中使用一对一关系或者是否有必要。
如果您只能选择查询中所需的列，是否有必要将表分解为一对一的关系。我想更新一个大表比更新一个小表对性能有更大的影响，我确信这取决于表用于某些操作（读/写）的程度
那么，在设计数据库模式时，如何考虑一对一关系呢？您使用什么标准来确定是否需要它，以及不使用它有什么好处？
从逻辑角度来看，1:1 关系应始终合并到单个表中。
另一方面，可能有physical对于此类的考虑“垂直分区”或“行分割”，特别是如果您知道您将比其他列更频繁地访问某些列或以不同的模式访问某些列，例如：
- 你可能想要cluster or 分割1:1 关系的两个“端点”表不同。
- 如果您的 DBMS 允许，您可能希望将它们放在不同的物理磁盘上（例如，对性能更关键的放在 SSD 上，另一个放在便宜的 HDD 上）。
- 您已经测量了对缓存的影响，并且希望确保“热”列保留在缓存中，而“冷”列不会“污染”它。
- 您需要比整行“更窄”的并发行为（例如锁定）。这是高度特定于 DBMS 的。
- 您需要对不同的列使用不同的安全性，但您的 DBMS 不支持列级权限。
- 触发器通常是特定于表的。虽然理论上您可以只有一个表并让触发器忽略该行的“错误的一半”，但某些数据库可能会对触发器可以执行的操作和不能执行的操作施加额外的限制。例如，Oracle 不允许您从行级触发器修改所谓的“变异”表 - 通过使用单独的表，只有其中一个可能会变异，因此您仍然可以从触发器修改另一个表（但有其他方法来解决这个问题）。
数据库非常擅长操作数据，所以我不会仅仅为了更新性能而拆分表，unless您已经对代表性数据量执行了实际基准测试，并得出结论，性能差异确实存在并且足够显着（例如，抵消了对 JOINing 增加的需求）。
另一方面，如果您谈论的是“1:0 或 1”（而不是真正的 1:1），那么这完全是一个不同的问题，值得不同的答案......
也可以看看：我什么时候应该使用一对一关系？
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
