[DB] 상속관계 모델링

김형진·2023년 5월 26일
0

O클래스를 상속받는 A,B,C 객체는 DB에서 어떻게 관리해야 할까?

세 가지 방법이 있는데,
1. 하나의 테이블을 생성하여 A,B,C 객체의 모든 필드를 컬럼으로 생성 (하나의 테이블에 A,B,C 다 때려박는 방식)
2. 공통된 필드를 저장하는 상위 테이블과, 상위테이블의 Id를 참조하는 A,B,C테이블을 각각 만든다.
O 클래스에서 정의된 공통 필드는 공통 테이블에서 관리하고, A,B,C 에서 사용하는 각각의 필드는 각각의 테이블에서 관리하되, 몸통은 O 테이블이므로 A,B,C 테이블이 O테이블의 PK를 참조하도록 하는 것이다.
3. A,B,C 각각의 테이블을 만든다.

이전에는 개발할 때에는 1번의 방식을 많이 사용했다.
상속관계에 있으면서 서로 다른 필드를 가진 객체들을 하나의 테이블에 관리하는 것은 DB관리가 용이하다는 장점이 있다.
단점으로 데이터낭비와 null값을 허용한다는 것이다.
전자의 단점은 체감으로 느낀 적이 딱히 없어 상관없는 느낌이었지만 후자의 단점의 경우 DB가 한 눈에 잘 들어오지 않고 지저분한 느낌이 들어 이후 저장방식을 바꾸게 되었다.

그 다음으로 사용한 방식은, 큰 틀에서는 1번의 방식을 사용하되 테이블에 ~info라는 컬럼을 추가해 서로 다른 필드의 정보를 전부 json으로 때려박아 관리하는 방법이었다.
null값이 허용되지 않기 때문에 이전보단 깔끔한 느낌이 들었으나 검색 조회나 update 시 json문법을 사용해야 한다는 단점이 있었다.

그래서 그 이후에는 2번의 방식을 사용하게 되었는데, 각 객체의 서로 다른 필드는 각각 테이블로 분리하여 관리하고, 공통된 필드는 root테이블에서 관리하도록 하였다.
조회 시 join을 사용해야 한다는 불편함이 있지만 가장 깔끔한 방법인 것 같다.

그래서 지금은 update나 조건조회가 잘 없는 경우 한 컬럼안에 다른 필드 정보를 json으로 때려박는 방식을 사용하고, 그렇지 않다면 테이블 상속관계를 사용한다.

참고로 3번의 경우, 논리적으로는 상속관계에 있지만 물리적으로는 완전히 분리되어있기 때문에 상속관계의 이점을 사용할 수 없어 잘 사용되지 않는다고 한다.

profile
히히

0개의 댓글