是否值得在集合价值协会中与'非常多'的一方使用@OneToMany关系？
当我们有很少的实例或严格的逻辑关系时，例如List<OrderLine>中的Order或Set<Phone>中的Person，我们很清楚我们会这样做。但是，当涉及到持有多个实例时，如Set<Order>中的Customer或List<Event>中的Company，Order#setCustomer()或Event#setCompany()之类的简单操作要求持久化上下文管理整个元素集合。是不是太贵了？或者在这些情况下应避免双向关系？
后续部分是这些关系的级联设置。将Customer / Company的合并/持久功能级联到其“子级”是合乎逻辑的，但最终不会浪费资源吗？
最后但并非最不重要的是级联删除。它完全符合所有四种关系。但是，如果我们留下单值关联的单向关系，那么我们必须在删除父级时使用查询单独删除子项？
现在，我只在项目数量很少且实体之间存在明确的父子关联时才使用双向关系。大部分工作都是通过单值结束（自行删除Order / Entity）并在删除父项后通过查询完成（删除Customer / {{ 1}}）。
在重读了一些关于JPA的书之后，我开始认为我可能没有遵循在Java EE应用程序中使用持久性的正确方法。
您对在Java EE应用程序中使用与集合中的许多实例的双向关系有什么看法？如果您特别选择单向关系，如何管理级联？
答案 0 :(得分：1)
如果集合非常大，那么您的解决方案可能是最好的。你最好先查询关系，而不是映射关系。但这取决于应用程序。