В моем приложении пользователи могут размещать статьи. И другим пользователям могут понравиться эти статьи.
Класс статьи:
@Entity
public class Article {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name = "article_id")
private int id;
@Column(name = "article_title")
private String articleTitle;
@OneToMany(mappedBy = "event")
private List<PeopleWhoLiked> peopleWhoLiked;
}
@Entity
public class PeopleWhoLiked {
@EmbeddedId
private PeopleWhoLiked id;
@ManyToOne @MapsId("articleId")
private Article article;
@ManyToOne @MapsId("userId")
private User user;
}
И есть сущность категории. Каждая статья имеет одну категорию.
public class Category {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name = "category_id")
private int id;
@NotEmpty
@Column(name = "categoryName")
private String categoryName;
@OneToMany(mappedBy = "article")
private List<Article> articleList;
}
Моя таблица лайков
Article_id User_id
x x
Это оба внешних ключа для связанных таблиц.
С участием
Функция category.getArticleList(); Я могу показывать статьи пользователям. Они могут ставить лайки, но дело в том, что система не знает, понравилась ли статья уже пользователю. Так что кнопка «Нравится» всегда активна.
Запрос (оператор выбора для каждой статьи в таблице Like) выглядит очень сложным по времени и перегружает систему.) Даже если я это сделаю, как я могу разместить это в операторе тимелеафа th:each только с объектом Article.
Я думаю, что запрос 10 подобных статей за раз с одним оператором выбора звучит хорошо. Но опять же, как я могу передать это тимелеафу с помощью объекта статьи.
Ваша проблема с производительностью вызвана дополнительным запросом для каждой строки.
Для 1 выбора, возвращающего 100 строк, вы делаете дополнительные 100 выборок в базе данных.
Если вам нужно отобразить сложное представление построения результатов, а затем сопоставить результат представления вашему классу @Entity, который будет использоваться только для целей презентации.