在SQL / MySQL中，有什么理由不将一对一关系放在同一个表中？
一对一关系通常可以存储在同一个表中。有什么理由不将它们存储在同一个表中？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
一对一关系通常可以存储在同一个表中。有什么理由不将它们存储在同一个表中？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（4）
列的数量和类型。表中列的大小有限制。请参阅此处。每行最多 8,060 字节。
非常大的表也会影响性能，并且可能难以很好地优化和索引。
这与保存数据不同，它们在概念上是不同的，彼此分开。例如，一个国家和货币有1对1的关系（说明性的例子，我知道情况并不总是如此）。我仍然不会让他们在一起。
Number and type of columns. There is a limit on the size of the columns in a table. See here. There is a maximum of 8,060 bytes per row.
Very large tables can also affect performance and can be difficult to optimize and index well.
This is apart from keeping data the is conceptually different, apart from each other. For example, a country and currency have a 1 to 1 relationship (illustrative example, I know this is not always the case). I would still not keep them together.
您将在 http://onlamp.com/pub/a/onlamp/2001/03/20/aboutSQL.html
最重要的是以下内容：
You'll find some information about when it's useful to create one-to-one relations under http://onlamp.com/pub/a/onlamp/2001/03/20/aboutSQL.html
The most important thing is following:
我这样做是为了防止锁定/阻塞，将读取的重列放在一个表中，将更新的重列放在另一个表中，就像一个魅力一样。许多大的更新事务减慢了很多读取速度。
I've done this to prevent locking/blocking, put the read heavy columns in one table the update heavy columns in another, worked like a charm. A lot of big fat update transactions were slowing down a lot of reads.
一对零或一关系很常见，并且从可选链接到强制关系 - http://onlamp.com/pub/a/onlamp/2001/03/20/aboutSQL.html 就是这种类型，不是一对一的。类型/子类型关系可以这样实现。
当每个关系都代表一个清晰的、有意义的实体时，就会出现一对一的关系，该实体在不同的上下文中可能处于某种不同的关系中，并且对需求的微小更改可能会改变关系的基数。哪个链接到哪个是任意的，因此最好选择一个作为可选，并将一转换为零或一。
One - to zero-or-one relationships are common and linked from the optional to the mandatory - the example given in http://onlamp.com/pub/a/onlamp/2001/03/20/aboutSQL.html is of this kind, not one-to-one. Type/subtype relations can be implemented like this.
one-to-one relations occur when each represents a clear, meaningful entity, which in a different context may be in some different relationship and where a minor change to the requirements may change the cardinality of the relation. It is arbitrary which links to which so its best to choose one to be optional and convert to one to zero-or-one.