在实际应用中，hibernate双向关联用的比较多，还是单向比较多？

Question

比如说user和conference之间，多对多关系，是用单向好还是双向好？

Answer 1

建议不要使用 ORM 的关联，这样会导致很差的性能！一般互联网应用的，绝对不允许使用关联查询，特别是一些很大的表更是不可以使用 LEFT JOIN 之类的查询，宁愿多查几次。

Answer 2

1：不建议在数据表中使用外键约束
2：不建议在 ORM 中使用各种关联
3：关联及外键控制在代码中做好控制

Answer 3

如果不用 Hibernate 直接用 JDBC 是不是就没办法写代码了？

Answer 4

目前写的项目是用到hibernate的，还有，跑题了

Answer 5

我不是太同意你的说法，要根据场合来决定。
1：不建议在数据表中使用外键约束
对于数据完整性要求很高而且关系很复杂的情况，使用外键可以得到最好的维护性（当然这也有用户体验不好的缺点，因为报错在数据库一级，前端不知道出错原因）。
否则你用代码维护得累死，因为你要让程序员去记住每个场景下的数据关联。
2：不建议在 ORM 中使用各种关联
最初使用ORM时我也有这样的困惑，不过当你把它们的关系处理好了，确实事半功倍。
多对多时我一般用两个一对多来处理，因为中间表可能也有自己的属性，用对多不太好处理。
一般来说对于数据关系双向查询非常的话我就双向维护，其实很难说单向好还是多向好，一般情况下还是多考虑双向。
比如楼主提的例子，user和conference。一般情况下肯定是在user中维护conference关系，因为多数场景下是通过user去找conference，反过来就很少。如果conference去找user也有场景，则也维护之。
3：关联及外键控制在代码中做好控制
这个在1中说明了。

Answer 6

user和conference之间是多对多的关系吧。一个用户可以参加多个会议，而一个会议会有多个人参加
表的话，弄个中间表就可以了
问题是在于究竟是用单向好，还是双向好。在实际应用中，是不是双向很少用？
双向的话，似乎维护不大方便，若增加一个和user有关的实体类，则user代码仍要改动，这么弄下来，user会弄得非常臃肿。想想通过user找conference，大部分需求是找最近需要开的会，以往开过的会议查找不是很频繁，我觉得只是维护conference到user的引用即可吧。