Правильный подход к агрегированию данных из нескольких таблиц в spring JPA
У меня есть раздел вопросов и ответов, где с каждым вопросом и ответом связана карточка профиля пользователя. Который отображает имя пользователя, баллы и т. д. Данные, составляющие эту карточку профиля пользователя, распределены по нескольким таблицам. Я извлекаю один или два столбца из каждой из этих таблиц. Теперь я не уверен, какой подход я должен использовать, чтобы связать карточку профиля пользователя с каждым вопросом и ответом.
Спасибо
Что я уже пробовал:
1. я не могу иметь прямой ассоциации в вопросе и ответе сущности, так как сама карта профиля пользователя не является единой сущностью, а является агрегированным объектом
2. Я рассмотрел создавая объекты переноса данных, а прогнозы для статистической обработки данных за вопрос и карты Профиль пользователя в ДТО, как показано ниже
@Query("select new com.QuestionDto(q.id, q.topic, q.views, ud.username, ur.points) from QuestionEntity q join UserDetails ud ON q.userId = ud.userId join userRanking ur ON ud.userId = ur.userId where q.id = :id")
QuestionDto findQuestionDto(@Param("id") Long id);
Проблема, которую я вижу в этом подходе, заключается в том, что будут такие DTO для ответа, комментариев и т. д. Поэтому всякий раз, когда происходит изменение карты профиля пользователя, мне нужно будет внести эти изменения во все DTOs соответственно. Что будет очень плохим дизайном с точки зрения ремонтопригодности кода.
3. Другой подход заключается в объединении данных карты профиля пользователя в сам DTO, а затем этот DTO будет вызываться из каждого вопроса, ответа и т. д. При таком подходе, по крайней мере, логика для карты профиля пользователя находится в одном месте.
@Query("select new com.UserProfileCard( ud.username, ur.points) from UserDetails ud join userRanking ur ON ud.userId = ur.userId where ud.userId = :id")
UserProfileCard getUserProfileCard(@Param("id") Long userId);
Но с другой стороны, если вопрос имеет 15 ответов, это приведет к (1 + 15) запросам для каждого пользователя. С точки зрения производительности я не считаю это очень эффективным.
А что еще? Есть ли какой-то другой подход, который мне не хватает, который хорош как с точки зрения ремонтопригодности кода, так и с точки зрения производительности?