哪种方法更适合基础和分拣速度？

Posted 2023-02-26

【中文标题】哪种方法更适合基础和分拣速度？

【英文标题】：Which method is more optimal for the base and sorting speed?

【发布时间】：2018-11-13 02:01:42

【问题描述】：

我目前有一个列表

@OneToMany(mappedBy = "movie", orphanRemoval = true, cascade = CascadeType.ALL, fetch = FetchType.LAZY)
@OrderBy("date ASC")
private List<MovieReleaseDateEntity> releaseDates = new ArrayList<>();

下载时的实体按日期排序。

但是，如您所知，List 不是最适合 JPA 的，建议使用Set。这就是为什么我有不同的想法

@OneToMany(mappedBy = "movie", orphanRemoval = true, cascade = CascadeType.ALL, fetch = FetchType.LAZY)
private SortedSet<MovieReleaseDateEntity> releaseDates = new TreeSet<>();

并实现Comparable

public int compareTo(MovieReleaseDateEntity o) 
    return this.date.compareTo(o.date);

哪种方式更好？第一个是List 还是第二个是Set？

【参考方案1】：

第一种方法（@OrderBy("date ASC")）在数据库级别排序，第二种方法在内存中使用 java 实现。如果返回的列表足够大，最好使用第一种方法。

如果返回的集合相当小并且您需要一些复杂的排序逻辑（但按特定字段排序不是您的情况），则使用 SortedSet 对实现 Comparable 的实体进行排序可能是合理的。

【讨论】：

例如，电影的其他标题的对象可以有，例如 max. 25左右。25大吗？

对我来说 25 绝对不是大尺寸。但如果大小约为 1000，它会变大:)

【参考方案2】：

数据库旨在以优化的方式执行order by 命令，同时对order by 中使用的列进行索引。 因此，如果您可以调整表上的索引约束，您应该支持数据库的排序。

但是，如您所知，列表并不是最适合 JPA 和 建议使用 Set。

我宁愿说您不能在实体中滥用List 映射，因为出于合理的原因（基数），可接受的数量是有限的。

您还可以更简单地看待事情：如果您的元素很少，我想使用Set 可能是一种可以接受的性能方式。 否则，使用List 和由数据库完成的order by 可能会受到青睐。

无论如何，请使用对您的用例来说似乎最合适的结构（List 或 Set），然后在更改设计之前测量实际性能以希望获得更好的性能。

【讨论】：

我的应用程序中有 MovieReleaseDateEntity，它存储了首映日期。基于 IMDB 网站imdb.com/title/tt6644200/releaseinfo?ref_=tt_dt_dt#releases，这部电影有 53 个首映日期。所以我的列表上有 53 个 (MovieReleaseDateEntity) 对象。你是否认为有太多的对象无法排序到java中？我的应用程序类似于 IMDB。或者最好不要对对象进行排序并返回未排序的对象？

53 是相当少的排序元素。所以在java或数据库中，它不应该改变很多东西。请注意，您还应该考虑您检索的实体的数量以及包含此MovieReleaseDateEntity 列表的实体的数量。如果您检索 100 个这些实体，这可能很重要。在任何情况下都不要进行过早的优化。根据功能需求使用您需要的结构。与TreeSet 相比，List 更容易为客户端操作，并且消耗的内存更少。因此，我首先会支持这种方式，并且只有在不可避免的情况下才会重构为TreeSet。