[JPA] 7. 고급 매핑

본 문서는 인프런의 자바 ORM 표준 JPA 프로그래밍 - 기본편 (김영한) 강의를 공부하며 작성한 개인 노트입니다.

🥽 상속관계 매핑

• 객체는 상속 관계가 있음
• 관계형 디비는 상속 관계가 없음
  • 슈퍼타입/서브타입 관계 모델링 기법이 객체 상속과 유사
• 상속관계 매핑: 객체의 상속구조와 디비의 슈퍼타입/서브타입 관계 매핑

주요 어노테이션

• @Inheritance(strategy=IneheritanceType.XXX)
  • JOINED: 조인 전략 > 이걸로 선택
  • SINGLE_TABLE: 단일 테이블 전략
  • TABLE_PER_CLASS: 구현 클래스마다 테이블 전략
• @DiscriminatorColumn(name="DTYPE") - 엔티티명을 dtype 설정
• @DiscriminatorValue("") - dtype 설정
  • 디폴트: 엔티티명

슈퍼타입/서브타입 논리 모델을 실제 물리 모델로 구현

• 조인 전략: 각각 테이블로 변환
  
  • PK/FK 값으로 조인
  • 잘 정규화된 모델
  • JPA와 가장 유사

  @Entity
  @Inheritance(strategy = InheritanceType.JOINED)
  @DiscriminatorColumn
  public class Album extends Item {
  		private String artist;
  }

  • 장점: 테이블 정규화, 외래키 참조 무결성 제약조건 가능 (부모 테이블에서 id 조회 한번으로 모든 테이블의 조회 가능), 저장공간 효율화
  • 단점: 조회시 조인을 많이 사용 > 성능 저하, 복잡한 조회 쿼리, 데이터 저장시 INSERT SQL 2번 호출
• 단일 테이블 전략: 통합 테이블로 변환
  
  • 프로젝트가 단순한 경우
  • 하나의 테이블에 다 때려박고 dtype으로 구분
  • 장점: 조인 필요 X, 조회 성능 주로 빠름, 조회 쿼리 단순
  • 단점: 자식 엔티티가 매핑한 컬럼은 모두 null 허용 (앨범은 무비 엔티티 필드 모두 null), 단일 테이블에 모든 것을 저장 > 테이블이 커져서 조회 성능이 느려질 수도
• 구현 클래스마다 테이블 전략: 서브타입 테이블로 변환 > 쓰면 안됨
  
  • Item 테이블 없이 공통 속성을 각 테이블마다 각각 추가함
  • DiscriminatorColumn 필요 없음
  • 디비 설계자 & ORM 전문가 둘다 추천 X
  • 장점: 서브타입이 명확하게 구분됨, not null 사용 가능
  • 단점: 조회 시 부모 클래스 타입으로 조회하는 경우에 비효율적으로 동작함, 자식 테이블을 통합해서 쿼리하기 어려움

    Item item = em.find(Item.class, id);

🏸 Mapped Superclass

공통 매핑 정보가 필요할 때 사용 (예) id, name

• BaseEntity 클래스를 이용해서 반복돼서 사용되는 속성은 상속으로 처리
• 공통 속성이 많을 때 (예) 등록일, 수정일, 등록자, 수정자 등
• 상속관계 매핑 X
• 엔티티 X & 테이블과 매핑 X
• 부모 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공
  • 부모 클래스로 조회/검색(em.find(BaseEntity)) 불가
• 직접 생성해서 사용할 일이 없음 > 추상 클래스 권장

@MappedSuperclass
public abstract class BaseEntity {
}

실전예제 4 - 상속관계 매핑

• 상품의 종류는 음반, 도서, 영화 & 이후 확장 가능
• 모든 데이터는 등록일/수정일 포함