상속관계 매핑

상속관계 매핑

• 관계형 데이터 베이스는 상속관계 X
• 슈퍼타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사
• 상속관계 매핑 : 객체의 상속과 구조와 DB 의 슈퍼타입 서브타입 관계를 매핑

주요 어노테이션

• @Inheritance(strategy=inheritanceType.XXX)
  • JOINED : 조인 전략
  • SINGLE_TABLE : 단일 테이블 전략
  • TABLE_PER_CLASS : 구현 클래스마다 테이블 전략
• @DiscriminatorColumn(name=”DTYPE”)
• @DiscriminatorValue(“XXX”)

테이블 만들 때 @Inheritance 어노테이션 붙히지 않으면 default 는 SINGLE_TABLE 즉 한 테이블에 다 박는 전략

@DiscriminiatorColumn을 적어주면 I tem 테이블에 DTYPE 뭐이런식으로 넣으면 ITEM 테이블에 insert 될 때 movie엔티티를 통해 넣었으면 ITEM 테이블 DTYPE 컬럼에 Movie가 들어감

싱글 테이블 전략에서는 무조건 DTYPE 과 같은 컬럼이 있어야 이 아이템이 어떤건지 구분할 수 있겠지?

조인 전략

장점

• 테이블 정규화
• 외래키 참조 무결성 제약조건 활용성
• 저장 공간 효율화 단점
• 조회 시 조인을 많이 사용, 성능 저하
• 조회시 쿼리가 복잡함 (잘만하면 사실 큰 문제 없다함)
• 데이터 저장 시 INSERT SQL 2번 호출

단일 테이블 전략

장점

• 조인이 필요 없으므로 일반적으로 조회 성능이 빠름
• 조회 쿼리가 단순함 단점
• 자식 엔티티가 매핑한 컬럼은 모두 null
• 단일 테이블에 모든 것을 저장하므로 테이블이 커질 수 있으며 상황에 따라 조회 성능이 오히려 느려질 수 있다.

구현클래스 마다 테이블 전략 -> 쓰지말자..

장점

• 서브 타입을 명확하게 구분해서 처리할 때 효과적
• NOT NULL 조건을 사용가능 단점
• 여러 자식 테이블을 함께 조회할 때 성능이 느림 (UNION ALL) 사용
• 자식 테이블을 통합해서 쿼리하기 어려움

---

@MappedSuperclass

멤버, 셀러 엔티티에 아이디, 네임이 중복 되니깐 공통 엔티티를 만들어서 쓰겠다는 느낌. DB는 따로

이런 식으로 중복되는 생성일 수정일 같은 걸 미리 만들고 Member 엔티티나 Team 엔티티 등에서 extents BaseEntitiy 로 상속받아서 사용

• 상속관계 매핑 아님
• 엔티티X , 테이블과 매핑도 아님
• 부모 클래스를 상속받는 자식 클래스에 매핑 정보만 제공
• 조회 검색 당연히 안됨
• 직접 생성해서 사용할 일이 없으므로 추상 클래스 권장 abstract !
• 테이블과 관계 없고, 단순히 엔티티가 공통으로 사용하는 매핑정보를 모으는 역할
• 주로 등록일, 수정일, 등록자, 수정자 같은 전체 엔티티에서 공통으로 적용하는 정보를 모을 때 사용
• 참고 : @Entity 클래스는 엔티티나 @MappedSuperclass로 지정한 클래스만 상속 가능