在 RDBMS 中，当关系是一对一时，如果两个记录都指向对方，或者一个指向已经足够（不需要两个都指向），这是否有帮助？
我正在读一本书，其中谈到 User 有更多 UserDetail，因此 UserDetail 将有一个 user_id 指向用户表。我有点忘记了，在 Users 表中有一个字段让 user_detail_id 指向 UserDetail 记录有帮助吗？
在 Ruby on Rails 中也是如此，Users 表没有 user_detail_id，但 UserDetail 表有 user_id。 User 模型使用 has_one :user_detail，而 UserDetail 模型使用 belongs_to :user。
这是有道理的，如果是一对多关系，那么在“Many”一侧，我们有一个 foreign_id 指向“One”一侧，但是“One”一侧side 不需要指向“Many”一侧，因此看起来一对一也不需要指向两个方向，因为一侧就足够了。
I was reading a book and it talks about a User has some more UserDetail, and so the UserDetail will have a user_id pointing back to the Users table. I kind of forgot that, does it help at all to has a field in Users table to have a user_detail_id to point at the UserDetail record?
This is so in Ruby on Rails too, that the Users table doesn't have a user_detail_id, but the UserDetail table has a user_id. And the User model use has_one :user_detail, while the UserDetail model use belongs_to :user.
It kind of makes sense that if it is a one-to-many relationship, then at the "Many" side, we have an foreign_id pointing back to the "One" side, but the "One" side doesn't need to point to the "Many" side, so it looks like a one-to-one doesn't need to have it pointing both ways too, as one side is enough.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这不是一个好主意，如果你想删除一行你会怎么做？您需要禁用该约束！
It's not a good idea, what would you do if you wanted to delete a row? You'd need to disable the constraint!
没错，就外键而言，只需为一个方向建立关系。请注意，Rails 中的 ActiveRecord 关联允许您从任一端遍历关联。例如：
That's correct, in terms of foreign keys the relationships only need to be set up for one direction. Note that ActiveRecord associations in Rails let you traverse the association from either end though. For example:
您永远不会在关系的双方都实现外键——如果不禁用约束，您将永远无法插入数据，因为约束要求信息同时存在于两个表中。两个表之一必须被视为父实体，其中子实体将依赖 Parent_id 来实现引用完整性...
但我认为您已经明白为什么通常不以一对一的方式对表进行建模- 一种关系。它通过将主键复制为外键（至少）来创建无意义的开销，并将外键约束作为额外的负担。为了解决性能问题，采用一对一的表；除非存在性能问题，否则就是过早的优化......
You never implement foreign keys on both sides of the relationship--you'd never be able to insert data without disabling the constraints because the constraints would require the information to exist in both tables at the same time. One of the two tables has to be considered the parent entity, where the child entity will rely on the parent_id for referential integrity...
But I think you're getting the idea why you don't generally model tables in a one-to-one relationship. It creates pointless overhead, by duplicating the primary key as the foreign key (at a minimum) and includes the foreign key constraint as additional baggage. One-to-one tables are resorted to in order to address performance issues; unless there is a performance issue, it's premature optimization...
在一对一的情况下，您可以将其完全视为一对多，只是“多”部分始终是“一”。话虽如此，在“多”端拥有外键就足够了，并且不需要任何双重指向。就这么简单。
In the case of a one-to-one, you can think of it exactly as a one-to-many except that the "many" part is always going to be "one". With that being said, having the foreign key on the "many" side is going to be good enough, and there is no need for any double pointing. It's as simple as that.