상속관계 매핑

상속관계 매핑

• 관계형 데이터베이스는 상속 관계가 없다.
• 상속관계 매핑이라는 것은, 객체의 상속 구조와 DB의 슈퍼/서브타입 관계를 매핑하는 것이다.

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

조인 전략

• 각각 테이블로 변환

단일 테이블 전략

• 통합 테이블로 변환

구현 클래스마다 테이블 전략

• 서브타입 테이블로 변환

@Inheritance(strategy = InheritanceType.XXX)

JOINED : 조인 전략 (기본적으로 사용)

• 생성
  
  
• 삽입
  
• 조회
  
• 부모 테이블의 PK = 자식 테이블의 PK이자 FK
• @DiscriminatorColumn : 기본 컬럼명 DTYPE, 부모 테이블에서 식별을 위해 사용
• @DiscriminatorValue : 자식 테이블에서 사용, DTYPE에 들어갈 값, 기본값은 클래스명
• 장점
  - 테이블 정규화
  - 외래 키 참조 무결성 제약조건 활용 가능 (ITEM_ID를 통한 편리함)
  - 저장공간 효율화
• 단점 (크진 않음)
  - 조회시 조인을 많이 사용하여 성능 저하, 쿼리 복잡함
  - 데이터 저장시 insert sql 2번 호출

SINGLE_TABLE : 단일 테이블 전략 (기본값), DTYPE 자동 생성 (데이터도 얼마 안되고 단순한 상황)

• 생성
  
• 조회
  
• 장점
  - 조인이 필요 없으므로 조회 쿼리가 단순해 성능이 빠름
• 단점
  - 자식 엔티티가 매핑한 컬럼 모두 null 허용
  • 하나의 테이블에 모든 것을 저장해 테이블이 커질 수 있으므로 조회 성능이 느려질 수 있다. (보통 이런 임계점을 넘는 일은 없다.)

TABLE_PER_CLASS : 구현 클래스마다 테이블 전략, 부모 테이블을 제외한 자식 테이블만 생성 (사용X)

• 생성
  
• 삽입
  
• 조회
  
• 명확한 테이블을 명시하면 바로 가져오지만, 부모 테이블에서 아는 값을 찾으려면 자식 테이블을 모두 조회해야 한다. (union all)
• 장점
  - 서브 타입을 명확하게 구분해서 처리할 때 효과적
  • 테이블이 따로 있기 때문에 not null 사용 가능
• 단점
  - 여러 자식 테이블을 함께 조회할 때 성능이 느림
  • 자식 테이블을 통합해서 관리하기 어려움 (새로운 자식 테이블이 생길 경우 복잡함)

전략만 바꿔주면 테이블 구조를 자유롭게 바꿀 수 있다!

에러

persistence.xml

<property name="hibernate.hbm2ddl.auto" value="create"/>

설정임에도 불구하고
Caused by: org.h2.jdbc.JdbcSQLSyntaxErrorException: Table "TEAM" already exists
에러 발생

해결

• h2 버전을 1.4.200 에서 1.4.199 로 변경
• pom.xml 에서 수정해도 안되길래 h2 홈페이지에서 1.4.199 jar파일 다운로드 및 200 jar 파일 삭제

실무에서는?

• 노가다를 하더라도 아이템에 때려 넣고 앨범, 북 등을 JSON으로..
• 데이터가 많아져서 파티셔닝하고.. 하면 상속관계 없이 테이블을 단순하게 유지해야 하는 경우도 있다.
• 정답이 없다ㅎㅎ
  
  

@MappedSuperclass - 매핑 정보 상속

• 공통 매핑 정보가 필요할 때 사용 (id, name, 등록/수정/삭제 정보 등)
• 운영에 필요한 정보이기 때문에 필수이다.
• 엔티티X, 테이블과 매핑X
• 부모 클래스를 상속받는 자식 클래스에게 매핑 정보만 제공한다.
• 조회, 검색 불가
• 직접 생성해서 사용할 일이 없으므로 추상 클래스로 사용해야 한다.
• 테이블과 관계 없고, 단순히 엔티티들이 공통으로 사용하는 매핑 정보를 모으는 역할
• 주로 등록일, 수정일, 등록자, 수정자 같은 전체 엔티티에서 공통으로 적용하는 정보를 모을 때 사용
• @Entity 클래스는 다른 @Entity 클래스나 @MappedSuperclass 클래스만 상속 가능