与非常多实体实例的双向关系的正确用例答案

【问题标题】：Right use case for bidirectional relationship with very many entity instances与非常多实体实例的双向关系的正确用例
【发布时间】：2013-08-13 14:01:23
【问题描述】：

是否值得在收藏价值关联中使用 @OneToMany 与“非常多”的关系？

当我们只有很少的实例或严格的逻辑关系时，如Order 中的List<OrderLine>，或Person 中的Set<Phone>，很明显我们会这样做。但是当涉及到持有许多实例时，如在Customer 中的Set<Order> 或Company 中的List<Event>，像Order#setCustomer() 或Event#setCompany() 这样的简单操作需要由持久性管理整个元素集合语境。是不是太贵了？或者在这些情况下应该避免双向关系吗？

相应的部分是这些关系的级联设置。将Customer/Company 的合并/持久化功能级联到它的“孩子”是合乎逻辑的，但最终不会浪费资源吗？

最后但并非最不重要的是级联删除。它显然非常适合所有四种关系。但是如果我们留下单值关联的单向关系，那么我们必须在删除父项时使用查询单独删除子项？

目前，我仅在项目数量非常少并且实体之间存在明确的父子关联时才使用双向关系。大部分工作是通过单值端（单独删除 Order/Entity）以及在删除父级后通过查询完成的（在删除 Customer/Company 时）。

在重读了一些关于 JPA 的书籍后，我开始认为我可能没有遵循在 Java EE 应用程序中使用持久性的正确方法。

您对在 Java EE 应用程序中对集合中的许多实例使用双向关系有何看法？如果您特别选择单向关系，您如何管理级联？

【问题讨论】：

标签： jakarta-ee jpa associations jpa-2.0

【解决方案1】：

如果集合非常大，那么您的解决方案可能是最好的。你最好查询关系，而不是映射它。但这取决于应用程序。

【讨论】：

感谢您的回答。我认为如果一个实体“包含”或“逻辑上拥有”另一个实体，那么双向映射关系通常是好的，但如果有很多实体（50/100+），或者逻辑关系是可疑（例如映射一组具有某种状态的用户）。但通常我坚持双向的。如果不这样做，我会调用其他 EJB 来处理删除操作。我做得对吗？
如果我没记错的话，JPA 映射本身不支持分页，所以对数据进行分页而不损失太多性能的唯一方法就是查询，对吧？当然，我不是在说特定于供应商的过滤器等。