Skip to content

Conversation

seokbeom00
Copy link
Contributor

💡 Issue

📄 Description

  • 문항세트 조회를 리팩토링했습니다.

@seokbeom00 seokbeom00 self-assigned this Apr 4, 2025
Copy link
Contributor

@sejoon00 sejoon00 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

고생했어요
쿼리는 중요한 부분인 것 같아서 같이 공부해봐요
추가로 더 좋은 방안이 있다면 의견부탁드려요

.leftJoin(conceptTag).on(
conceptTag.id.in(problem.conceptTagIds)
.or(conceptTag.id.in(childProblem.conceptTagIds))
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

현재 문항과 자식 문항을 조인한 뒤에 개념 태그까지 조인하다 보니, 카티시안 곱처럼 중복 데이터가 많이 생길 것 같아요. 특히 problem의 전체 컬럼을 다 가져오고 있어서 불필요한 데이터가 반복돼 성능상 부담이 될 수 있어요.

그래서 한 번에 모든 걸 가져오는 방식보다는, 문항과 자식 문항까지만 조인한 후, 개념 태그는 별도의 쿼리로 분리해서 조회하는 게 더 나을 것 같아요. 이렇게 하면 개념 태그 쿼리도 재사용하기 쉽고, concept_tag에 PK 인덱스가 잘 잡혀 있으니 성능도 더 좋아질 수 있어요.

다만, 개념 태그 쿼리가 문항마다 따로 나가는 건 비효율적이라 IN 절을 이용해서 한 번에 가져오는 방식으로 처리해야 할 것 같아요. 그리고 결과를 문항에 맞게 잘 매핑해주는 로직이 필요할 텐데, 이 부분은 따로 매퍼를 만들어서 정리해보면 좋을 것 같아요.

List<ProblemSummaryResponse> orderedSummaries = problemIds.stream()
.map(mapped::get)
.filter(java.util.Objects::nonNull)
.toList();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

정렬하는 로직은 어플리케이션보다 db가 잘할 수 있어요.
조회되는 문항이 많지 않으니 db에서 problemId로 정렬해서 가져오는건 어떨까요?
현재 DB에서 가져온걸 groupBy를 어플리케이션에서 하고 있는데 db에서 groupby를 하는게 좋을지 어플리케이션에서 할지도 고민해보면 좋을 것 같아요

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

♻️ 문항세트 조회 리팩토링

2 participants