Skip to content

[Feature]: N:M 명시적 중계 엔티티 승격 및 Fetch Join N+1 최적화 #7

Description

@devikae

Package Scope

  • Add to an existing package
  • New package
    Package name: backend

Overview
회원(Member)과 스키장(Resort), 라이딩 스타일(RidingStyle) 간의 N:M 다대다 관계를 명시적 중계 엔티티로 구현하고, 단일 대리키(id BIGINT AUTO_INCREMENT) 적용 및 JPQL Fetch Join으로 N+1 조인 쿼리를 최적화

Describe the solution you'd like
고민했던 방식:

  • JPA Direct @manytomany: 엔티티 간 직접 @manytomany 연관관계 매핑.
  • 중계 엔티티 + 복합키 (@EmbeddedId): 중계 엔티티 구현 후 (Member_ID, Resort_ID) 복합키 사용.
    선택한 방식:
  • 명시적 중계 엔티티 + 단일 대리키 (id): MemberResort, MemberRidingStyle 작성 및 단일 대리키 id 주입.
    이 방식을 선택한 이유:
  • Direct @manytomany는 연관 데이터 수정 시 중계 테이블 전체 레코드를 DELETE 후 RE-INSERT하는 쿼리 비효율이 발생하며 추가 컬럼 할당이 불가능함.
  • 복합키 방식은 JPA 영속성 관리 및 식별자 매핑 복잡도가 증가함.
    트레이드오프 및 극복 방안:
  • Trade-off: 연관 엔티티 조회 시 N+1 쿼리가 발생할 수 있음.
  • 해결 방안: 중계 엔티티에 단일 대리키 id를 적용하여 비식별 관계 구조로 단순화하고, 프로필 수정 시 기존 중계 레코드 deleteAll 후 saveAll Batch 갱신으로 처리함. N+1 문제는 JPQL JOIN FETCH 쿼리를 작성하여 단 1회의 SQL 조인으로 일괄 조회하도록 최적화.

Additional context
N:M 프로필 수정 시 중계 테이블 데이터 갱신 무결성 및 JPQL Fetch Join 단 1회 쿼리 실행 최적화 검증 완료.

Metadata

Metadata

Labels

enhancementNew feature or request

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions