@seongjunnoh @hd0rable 현재 위쪽에서 이미 vote 테이블과 voteItem 테이블을 조인하지 않고 vote만 조회한 후, 각 Vote에 대해 개별적으로 voteItem을 조회하고 있습니다. 만약 양방향 매핑이 되어 있다면 getVoteItemJpaEntities()를 통해 접근할 수 있지만, 현 구조에서는 각 Vote에 대해 별도의 select 쿼리가 발생하므로 결과적으로 N+1 문제가 발생할 수 있는 구조라고 생각됩니다.
현재는 상위 3개의 투표만 조회하므로 총 4개의 쿼리로 끝나지만, 이후 다른 기능들(특히 기록장 조회 API)에서도 Vote와 VoteItem은 자주 함께 사용될 가능성이 높아 보입니다. 따라서 성능 측면에서도 양방향 매핑을 추가한 뒤 fetch join을 고려하는 방식이 더 나을 수 있지 않을까 조심스럽게 제안드립니다..!
Originally posted by @buzz0331 in #75 (comment)
@seongjunnoh @hd0rable 현재 위쪽에서 이미 vote 테이블과 voteItem 테이블을 조인하지 않고 vote만 조회한 후, 각 Vote에 대해 개별적으로 voteItem을 조회하고 있습니다. 만약 양방향 매핑이 되어 있다면
getVoteItemJpaEntities()를 통해 접근할 수 있지만, 현 구조에서는 각 Vote에 대해 별도의 select 쿼리가 발생하므로 결과적으로 N+1 문제가 발생할 수 있는 구조라고 생각됩니다.현재는 상위 3개의 투표만 조회하므로 총 4개의 쿼리로 끝나지만, 이후 다른 기능들(특히 기록장 조회 API)에서도 Vote와 VoteItem은 자주 함께 사용될 가능성이 높아 보입니다. 따라서 성능 측면에서도 양방향 매핑을 추가한 뒤 fetch join을 고려하는 방식이 더 나을 수 있지 않을까 조심스럽게 제안드립니다..!
Originally posted by @buzz0331 in #75 (comment)