[Spring JPA] 슈퍼-서브타입 관계 모델링 (상속관계 매핑)

 

DB 모델링기법 중에 슈퍼-서브타입 모델링(엔티티가 상속관계를 이룸)이라는게 있는데,

논리모델은 같지만 실제 물리모델은 RollUp, RollDown, Identity 중 하나로 구현한다.

 

[SQL] 슈퍼-서브타입 모델의 물리모델 결정기준 (feat. JPA)

 

 

즉, 물리모델중 어느 방법으로 구현하냐에 따라서

테이블의 구조와 갯수가 변동된다.

 

 

실제 서비스 중,

성능이 너무 안나와서 다른 물리모델로 교체하자라는 콜이 나왔을 때

JPA가 없다면 뜯어고칠게 엄청많을 것이다.

 

 

하지만 JPA와 함께라면,

두려움없이 코드 몇줄의 수정으로

입맛에 맞추어 물리모델에 매핑시킬 수 있다.

 

 

JPA의 가장 큰 장점 중 하나라고 할 수 있다.

 

---

 

# 예시 논리모델

 

 

 

# 코드 베이스 

1. [물품 - Item] - 슈퍼타입

//@Getter ...~~ @ NoArgsConstructor // 본인 입맛대로 
@Entity
public abstract class Item{
    @Id @generatedValue
    private Long id;
    
    private String name;
    private BigDecimal price;
}

2. [음반 - Album] - 서브타입

//@Getter ...~~ @ NoArgsConstructor // 본인 입맛대로 
@Entity
public class Album extends Item{
    private artist;
}

3. [영화 - Movie] - 서브타입

//@Getter ...~~ @ NoArgsConstructor // 본인 입맛대로 
@Entity
public class Movie extends Item{
    private director;
}

4. [책 - Book] - 서브타입

//@Getter ...~~ @ NoArgsConstructor // 본인 입맛대로 
@Entity
public class Book extends Item{
    private author;
}

---

 

# 물리모델에 따른 매핑 변경

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

  >> Single_Table , Table_Per_Class , Joined

 

1. RollUp (Single-Type)

//@Getter ...~~ @ NoArgsConstructor // 본인 입맛대로 
@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
public abstract class Item{
    @Id @generatedValue
    private Long id;
    
    private String name;
    private BigDecimal price;
}

2. RollDown (Plus-Type)

//@Getter ...~~ @ NoArgsConstructor // 본인 입맛대로 
@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public abstract class Item{
    @Id @generatedValue
    private Long id;
    
    private String name;
    private BigDecimal price;
}

3. Identity (One-To-One Type)

//@Getter ...~~ @ NoArgsConstructor // 본인 입맛대로 
@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에 따라 아이템을 찾을때나 여러모로 골치아픔)