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

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

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

 

 

# 논리모델

* 전구모양의 x는 exclusive (x가없으면 inclusive)

 

 

# RollUp (Single-Type)

 하나의 테이블로 통합

# RollDown (Plus-Type)

 슈퍼타입을 각각의 서브타입에 추가하여 분리

# Identity (One-To-One Type)

 슈퍼타입과 각각의 서브타입을 테이블로 생성

 

---

 

# 슈퍼-서브타입 모델 비교

https://eehoeskrap.tistory.com/57

 

 

# 물리모델 결정기준

 데이터의 양과 트랜잭션의 유형에 따라 선택한다.

 

1. 개별로 발생되는 경우가 많은 서비스는 Identity로 !

 위의 논리모델에서 예를 들자면, 아이템의 가격정보를 먼저 조회하는 경우는 많지만

각 유형의 세부정보는 열람할수도 아닐수도 있을 상황에 안성맞춤! (발생로직이 분리되어있음!)

 

2. 슈퍼타입+서브타입에 대해 발생되는 서비스는 RollDown 으로!

 서브타입(ALBUM, MOVIE, BOOK) 에 각 200만건, 90만건, 10만건 이 있다고 가정하자.

 

책을 조회하고싶다...!

Single 타입(RollUp)으로 구성했을 경우, 300만건 중에 10만건만 조회하는 불필요한 성능저하가 발생한다.

OneToOne 타입으로 구성했을 경우, 계속 조인이 발생한다.

 

3. 전체를 하나로 묶어 트랜잭션이 발생할 때는 RollUp 으로!

 서브타입(ALBUM, MOVIE, BOOK) 에 각 10만건, 20만건, 270만건 이 있다고 가정하자.

 

비즈니스로직상 항상 앨범과 영화, 책을 같이 통합하여 처리해야한다고 하면

Single 타입(RollUp)이 아닌 경우, 불필요한 조인이나 UNION ALL 이 발생한다.

 

따라서, RollDown 으로 구성할경우, PK를 하나로 묶어 SEQUENCCE로 생성하는게 좋다.

 

---

JPA !

 

해당 모델들은 JPA로 구현한다면 아주 간단하게 구현할 수 있고,

물리모델이 바뀌어도 코드 몇줄로 간단히 물리모델을 바꿔 매핑할 수 도있다...!

 

보러가기