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회 쿼리 실행 최적화 검증 완료.

Activity

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

Metadata

Metadata

Labels

enhancementNew feature or request

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions