상속관계 매핑
- 관계형 데이터베이스는 상속관계를 갖고 있지 않다.
- 슈퍼타입, 서브타입 관계라는 모델링 기법이 개체 상속과 유사하기 때문에 이 방법을 대신 사용한다.
- 슈퍼타입, 서브타입 논리모델을 실제 물리 모델로 구현하는 방법
- 조인 전략: 각각 테이블로 변환
- 단일 테이블 전략: 통합 테이블로 변환
- 서브타입 테이블로 변환: 구현 클래스마다 테이블 전략
주요 어노테이션
@Inheritance(starategy=InheritanceType.XXX)- JOINED: 조인 전략
- SINGLE_TABLE: 단일 테이블 전략
- TABLE_PER_CLASS: 구현 클래스마다 테이블 전략
@DiscriminatorColumn(name=”DTYPE”)
@DiscriminatorValue(”XXX”)
조인 전략
- 각 서브타입의 PK와 슈퍼타입의 PK가 같기 때문에
JOIN으로 가져올 수 있다.
- 뿐만 아니라, 수퍼타입의
DTYPE을 통해서 타입을 분류할 수도 있다.DTYPE이 없으면,ITEM테이블만 봤을 때 어떤 엔티티인지 알 수가 없다.
- 장점
- 테이블 정규화
- 외래 키 참조 무결설 제약조건 활용가능
- 저장공간 효율화
- 단점
- 조회시 조인을 많이 사용하기 때문에 성능 저하
- 조회 쿼리가 복잡함
- 데이터 저장시 INSERT 쿼리 2번 호출
단일 테이블 전략
- 하나의 테이블에 모두 때려박는 방법.
DTYPE이 반드시 필요하다.@DiscriminatorColumn(name=”DTYPE”)이 default로 들어간다.
- 만약 없으면… 해당 column이 어느 엔티티인지 알아낼 방법 자체가 없다.!
- 장점
- 조인이 필요 없으므로 일반적으로 조회 성능이 빠르다.
- 조회 쿼리가 단순하다.
- 단점
- 자식 엔티티가 매핑한 컬럼은 모두 null을 허용해야한다.
- 단일 테이블에 모든 것을 저장하므로 테이블이 커질 수 있다. 따라서, 조회 성능이 오히려 더 낮아질 수도 있다.
구현 클래스마다 테이블 전략
- DBA나 ORM전문가 모두 기피하는 제일 비효율적인 전략이다.
- 반드시 수퍼 타입을
abstact class로 설정해야한다.
- 장점
- 서브 타입을 명확하게 구분해서 처리할 때 효과적이다.
- not null 제약조건 사용 가능하다.
- 단점
- 여러 자식 테이블을 함께 조회할 때 성능이 느리다(
UNION쿼리 필요).- ex) 자식 타입이 아니라 부모 타입으로 조회할 때, 모든 자식을 다 뒤져봐야한다.
- 자식 테이블을 통합해서 쿼리하기 어렵다.
- ex) 만약에 전체 정산을 해야하면.. 모든 자식을 다 조회해서 price를 가져와야한다.
- 여러 자식 테이블을 함께 조회할 때 성능이 느리다(
@MappedSuperclass
- 테이블과 관계 없고, 단순히 엔티티가 공통 매핑 정보를 모으는 역할을 할 때 사용한다.
- 엔티티도 아니고, 테이블과 매핑하고 싶지도 않을 때 사용한다.
- 부모 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공한다.
- 조회, 검색이 불가능하다(테이블이 아니니까!)
- ex) 등록일, 수정일, 등록자, 수정자 같은 전체 엔티티에서 공통으로 적용하는 정보를 모을 때 사용한다.
- 직접 생성해서 사용할 일이 없으므로, 추상 클래스로 사용하기를 권장한다.
- 참고: @Entity 클래스는 엔티티나 @MappedSuperclass로 지정한 클래스만 상속 가능하다.
Uploaded by N2T
(23.06.12 10:36)에 작성된 글 입니다.
