DB 모델링기법 중에 슈퍼-서브타입 모델링(엔티티가 상속관계를 이룸)이라는게 있는데,
논리모델은 같지만 실제 물리모델은 RollUp, RollDown, Identity 중 하나로 구현한다.
DB 슈퍼-서브타입

즉, 물리모델중 어느 방법으로 구현하냐에 따라서 테이블의 구조와 갯수가 변동된다.

실제 서비스 중 성능이 너무 안나와서 다른 물리모델로 교체하자라는 요청이 왔을때, JPA가 없다면 뜯어고칠게 엄청많을 것이다.

하지만 JPA와 함께라면,두려움없이 코드 몇줄의 수정으로 요청대로 물리모델에 매핑시킬 수 있다.

그 방법을 알아보자.
(개념은 DB의 슈퍼-서브타입부분에서 알아봤으므로 구현위주로 살펴보겠다)

예시 논리모델은 아래와같다.

코드 베이스

[Item] - 슈퍼타입

@Entity
public abstract class Item{
    @Id @generatedValue
    private Long id;
    
    private String name;
    private BigDecimal price;
}

[Album] - 서브타입

@Entity
public class Album extends Item{
    private artist;
}

[Movie] - 서브타입

@Entity
public class Movie extends Item{
    private director;
}

[Book] - 서브타입

@Entity
public class Book extends Item{
    private author;
}

물리모델에 따른 매핑 변경

@Inheritance 을 이용한 한줄로 매핑변경이 가능하다.

• Single_Table , Table_Per_Class , Joined

RollUp (Single-Type)

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
public abstract class Item{
    @Id @generatedValue
    private Long id;
    
    private String name;
    private BigDecimal price;
}

RollDown

@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public abstract class Item{
    @Id @generatedValue
    private Long id;
    
    private String name;
    private BigDecimal price;
}

Identity (One-To-One Type)

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
public abstract class Item{
    @Id @generatedValue
    private Long id;
    
    private String name;
    private BigDecimal price;
}

JPA에서의 각 전략의 장단점

1. Joined 전략

• insert 쿼리가 두번 나간다. (영한님께서 큰 단점은 아니라고 하신다)
• 확장에 용이하기때문에 비즈니스적으로 복잡할때 많이 사용

2. Single_Table 전략

• 일반적 조회성능이 빠름 (데이터의 갯수가 어느 분기점을 넘으면 성능이 저하)
• 자식엔티티의 컬럼은 모두 nullable. (데이터무결성에 문제)
• 비즈니스적으로 단순할때 많이 사용 (확장에 썩 용이하진 않음)

3. Table_Per_Class 전략

• DB 설계자와 ORM 전문가 둘다 비호인 전략
  (묶어서 정산이나, ID에 따라 아이템을 찾을때나 여러모로 골치아픔)