OneToMany - 连接表和外键之间有什么区别?
可以使用 @JoinColumn
注释禁用 @OneToMany
关系连接表。默认是连接表。
例如,生产系统的优点和缺点是什么?
什么时候应该使用连接表,什么时候不应该使用?
谢谢。
There is the possibility to disable the @OneToMany
relationship join table with the @JoinColumn
annotation. The default is a join table.
What are the advantages and disadvantages for a production system for example?
When should I use a join table and when not?
Thank you.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
默认情况下,仅当您使用单向关系时,
@OneToMany
才会创建连接表。换句话说,如果您有
Employee
和Project
实体,并且Employee
实体定义如下(假设没有>orm.xml
这些实体的条目):JPA 提供者将创建一个连接表(请注意,
mappedBy
属性>@OneToMany 注释,因为没有引用来自Project
的Employee
实体)。另一方面,如果您使用双向关系:
将不会使用连接表,因为将使用“多”端来存储此关系的外键。
但是,即使在定义的
mappedBy
属性具有双向@OneToMany
关系的情况下,您也可以强制使用联接表。您可以使用@JoinTable
< 来实现它/a> 关系所属方的注释。正如您所提到的,在默认情况下使用连接表(单向
@OneToMany
关系)的情况下,也可以使用@JoinColumn
。最好亲自测试 FK 和连接表的性能差异。我只能猜测较少的连接(在本例中:FK)似乎具有更好的性能。
此外,有时 DBA 定义了数据库模式,您只需将映射调整到现有模式即可。那么你就别无选择 FK 或连接表 - 这就是你有选择的原因。
By default
@OneToMany
will create a join table only if you'll use unidirectional relationship.In other words, if you have
Employee
andProject
entities and theEmployee
entity is defined as follows (assume there is noorm.xml
entries for these entities):the JPA provider will create a join table (notice there is no
mappedBy
attribute in@OneToMany
annotation as there is no reference toEmployee
entity from theProject
).On the other hand, if you'll use bidirectional relationship:
The join table will not be used, as there "many" side will be used to store the foreign key for this relationship.
However, you can force to use join table even in cases when you have bidirectional
@OneToMany
relationship with definedmappedBy
attribute. You can achieve it using@JoinTable
annotation on the owning side of the relationship.There is also a possibility, as you've mentioned, to use
@JoinColumn
in case where join table would be used by default (unidirectional@OneToMany
relationship).It's best to test the FK and join table performance difference for yourself. I can just guess that less joins (in this case: FK) seems to have better performance.
Moreover, sometimes the DBA defines the database schema and you just need to fit your mappings to the existing schema. Then you have no choice over FK or join table - that's why you have a choice.
多态性需要连接表。例如,如果 Employee 和 Manager 链接同一个项目,并且它们使用每类一表策略进行映射,则在关系数据库级别,了解该项目( id = 1, emp_id = 10 )引用经理的唯一方法就是将emp_id放入manager_2_employee表中。如果不是这种情况,那么emp_id可以直接进入项目。
Join tables are needed for polymorphisms. E.g., if Employee and Manager links the same project and they are mapped with one-table-per-class strategy, at the relational DB level, the only way to know that project( id = 1, emp_id = 10 ) refers to a manager is to put emp_id in the manager_2_employee table. If one is not in such a situation, then emp_id can go directly into project.
正如上面评论中提到的,默认情况下,hibernate 用于连接表。
这会带来更好的数据库标准化。
如果可以选择,JoinColumn 可以提供比连接表更好的性能,因为消除了在 SQL 查询中连接额外表的需要。
As mentioned in comments above, by default hibernate goes for join table.
This results in better db normalization.
If having a choice, JoinColumn gives better performance over the join table as need for the joining of an extra table in the SQL Query is removed.