Database 为什么在数据库设计中使用一对一的关系

发布于03月14日

我很难确定何时在db设计中使用1对1关系，或者是否有必要.

如果您只能 Select 查询中需要的列，那么是否有必要将表拆分成一对一的关系.我猜更新大表比更新小表对性能的影响更大，我确信这取决于表在某些操作(读/写)中的使用率

那么，在设计数据库模式时，如何考虑一对一关系呢？你用什么标准来确定你是否需要一个，不使用有什么好处？

推荐答案

从逻辑的Angular 来看，1:1的关系应该总是合并到一个表中.

另一方面，对于这样的"vertical partitioning"或"行拆分"，可能有physical个注意事项，尤其是如果您知道访问某些列的频率更高，或者访问方式与其他列不同，例如:

您可能希望以不同方式将1:1关系的两个"端点"表设置为cluster或partition.
如果您的DBMS允许，您可能希望将它们放在不同的物理磁盘上(例如，SSD上的性能更为关键，而另一个则放在廉价的硬盘上).
您已经测量了对缓存的影响，希望确保"热"列保留在缓存中，而"冷"列不会"污染"缓存.
您需要一个比整行"窄"的并发行为(如锁定).这是高度特定于DBMS的.
不同的列需要不同的安全性，但DBMS不支持列级权限.
触发器通常是特定于表的.虽然理论上您可以只有一个表，并且让触发器忽略行的"错误的那一半"，但是一些数据库可能会对触发器可以和不能做的事情施加额外的限制.例如，Oracle不允许您从行级触发器修改所谓的"变异"表-通过使用单独的表，它们中只有一个可能会发生变异，因此您仍然可以从触发器修改另一个表(但有other ways个表需要解决).

数据库非常擅长处理数据，所以我不会仅仅为了更新性能而拆分表，unless您已经对代表性的数据量执行了实际基准测试，并得出结论，性能差异确实存在并且足够显著(例如，抵消了加入的需求增加).

另一方面，如果您谈论的是"1:0或1"(而不是真正的1:1)，这是一个完全不同的问题，应该得到不同的答案……