@OneToMany注释有用吗？

Question

在宠物项目中使用这样的注释似乎工作得很好，我是老板，有两个员工等等。但在实际规模的项目中，你会结束与100.000调用相关的会计年度或拥有1.000.000公民的城市并天真地尝试在ArrayList中检索所有这些导致OutOfMemory错误。

一个好的方法是不定义这样的关系（但是@ManyToOne）并检索分页的结果，以便用它们做任何你想做的事。

那么，是否有任何Observer模式或类似处理大型数据库模型？ ¿您可以用来管理内存的任何配置？

Answer 1

我们假设您有一个应用程序，显示特定城市的所有公民数据。这个城市有1.000.000公民，所以你想在用户界面上显示这么多行。

您认为一次显示这么多数据是否有意义，或者您认为分页是否必要？我说后者就是这种情况，因为没人会读取UI上的100万条记录。

只是建议一些事情，如果您有这么多数据，请不要使用实体来显示UI上的信息。使用包含您需要显示的确切数据的投影+您也可以轻松地引入分页。

有多种方法可以定义投影，最简单的方法是使用基本定义界面的Spring Data JPA功能。

当然，如果你有一份必须处理所有公民的工作，那么同时获取所有内容但是做某种批量执行并不是一个好主意。将数据拆分为单独的部分，然后处理这些部分。在这种情况下，使用预测也是一个好主意。

Answer 2

嗯，这是应用程序架构的问题。我无法想象他们的城市拥有100万用户的商业价值，但我可以想象当我需要由用户或宠物所有者获得城市时的情况。

所以只要使用ORM了解其后果，$limit = request('limit'); $gap = request('gap'); 就不是反模式。

作为开发人员或应用程序架构师，您必须最好地了解您的域名，并且您应该知道解决方案何时适合。

Answer 3

在某些OneToMany关系中，相关对象的数量可能会变得太大，但有许多现实生活中的例子并非如此。如果您要使用Scrum团队成员创建Scrum Team对象，理想情况下，此数量将为3-9个对象。这很少，OneToMany非常有用。

但你提出的观点是有效的：如果数据太多，至少要加载延迟，即使这样，记录的数量也会变得太大。如果是这种情况，我可以想象OneToMany根本不方便。在这种情况下，我会转向Spring Data，有一个查询方法可以给我一个太大的页面列表。然后我确实会删除OneToMany，因为我再也不会使用它了。

有些方面注意：我总是做另一方：ManyToOne，所以我可以使用mappedBy并让我的数据库用外键创建更好的表，而不是之间的新表。这通常会对性能有所帮助，并且在某种程度上我感觉您现在可以在一次调用中加载更多对象。但是......如果有太多的记录要加载，你不想进入这个危险区域，所以我仍然删除那个OneToMany。

Answer 4

正如其他答案已经解释过的那样，在极端情况下拥有一个功能齐全的@OneToMany关联是个坏主意。

但是，这种关联仍然可以使用的情况是JPQL / HQL查询，因为您可以使用来自父实体的路径导航。为了确保不访问集合，您可以在集合的私有字段中提供映射，而不会为其公开getter和setter（当然，让关联保持懒惰）。