RDB에는 상속이라는 개념이 없음
슈퍼타입 서브타입 관계 (Super-Type Sub-Type Relationship)라는 모델링 기법이 상속과 유사
ORM에서 말하는 상속 관계 매핑 -> 객체의 상속 구조와 데이터베이스의 슈퍼타입 서브타입 관계 매핑
조인(기본키 + 외래키) 전략
단일 테이블 전략
테이블 마다 필요한 컬럼을 모두 부여
@Inheritance(strategy = InheritanceType.TYPE)
상속 매핑은 부모 클래스에 어노테이션 선언
매핑 전략을 지정 (strategy)
JOINED, SINGLE_TABLE, TABLE_PER_CLASS
@DiscriminatorColumn(name = "DTYPE")
부모 클래스에 구분 컬럼 지정
자식 테이블 구분 가능
기본값은 DTYPE
JPA 표준은 구분 컬럼을 사용하도록 하지만, Hibernate를 포함한 몇몇 구현체들은 없어도 동작
@DiscriminatorValue("M")
Entity를 저장할 때 구분 컬럼에 입력할 값을 지정
만약 영화 Entity를 저장하면 구분 컬럼인 DTYPE에 값 M이 저장.
@PrimaryKeyJoinColumn(name = "ex_id")
기본값으로 자식은 부모의 기본키 명을 그대로 사용
만약 기본키 명을 변경하고 싶을 때, 사용하는 어노테이션
엔티티 각각을 모두 테이블로 만들고, 자식이 부모의 기본키를 받아서 기본키 + 외래키 전략을 사용
객체는 타입을 구분할 수 있지만 테이블은 타입의 개념이 없음
따라서 타입을 구분하는 컬럼을 추가
strategy = InheritanceType.JOINED
장점
테이블 정규화
무결성 제약조건 활용 가능
저장공간 효율적 사용
단점
조회 쿼리가 복잡
조회할 때 조인이 많이 사용 -> 성능 저하 가능성
데이터를 등록할 INSERT SQL을 두번 실행
테이블 하나만 사용하는 전략
구분 컬럼으로 어떤 자식 데이터가 저장되었는지 구분
조회시에 조인을 사용하지 않기 때문에 가장 빠름
자식 Entity가 매핑한 컬럼은 모두 null을 허용해야 함
구분 컬럼을 반드시 사용해야 함
@DiscriminatorValue를 지정하지 않으면 기본으로 Entity 이름을 사용
strategy = InheritanceType.SINGLE_TABLE
장점
조인이 필요 없으므로 일반적으로 조회성능이 가장 빠름
조회 쿼리가 단순
단점
자식 Entity가 매핑한 컬럼은 모두 null 허용
단일 테이블에 모든 것을 저장하기 떄문에 테이블이 커질 수 있음
그렇기 때문에, 상황에 따라서 조회 성능이 더 느릴 수 있음
자식 Entity 마다 테이블을 생성
권장하는 방식은 아님
장점
서브 타입을 구분해서 처리할 때 효과적
not null 제약 조건 사용 가능
단점
여러 자식 테이블을 함께 조회할 때 성능이 느림 (UNION 사용)
자식 테이블을 통합해서 쿼리하기 어려움