단일 테이블 전략
테이블을 하나만 사용하고, 구분 컬럼(DTYPE)으로 어떤 자식 데이터가 저장되었는지 구분합니다.
장점
- 조인이 필요 없으므로 일반적으로 조회 성능이 빠르다
- 조회 쿼리가 단순하다
단점
- 자식 엔티티가 매핑한 컬럼은 모두 null을 허용해야 한다
- 단일 테이블에 모든 것을 저장하므로 테이블이 커질 수 있다. 그러므로 상황에 따라서는 조회 성능이 오히려 느려질 수도 있다
특징
- 구분 컬럼을 꼭 사용해야 합니다. 따라서 @DiscriminatorColumn을 꼭 설정해야 합니다.
- @DiscriminatorValue를 지정하지 않으면 기본으로 엔티티 이름을 사용합니다
주의!
- 슈퍼클래스에 abstract를 꼭 붙여야 하나요?
=> 아닙니다. 필수가 아닌 선택 사항이지만 붙이는 것이 좋습니다.데이터 무결성을 보장 해주기 위해서 슈퍼 클래스가 인스턴스로 생성되는 것을 사전에 예방 해주기 위해서 abstract를 붙여서 추상 클래스로 선언 해주는게 좋다
배경
상황 : 서비스에서 선생님, 학부모, 원장님 이라는 서로 다른 권한의 유저가 있고, ERD를 작성 하면서 관계 매핑을 어떻게 할지 토론 하던중, join전략과 단일 테이블 전략 두 가지 중에서 고민하게 되었다.
결론 : 각각의 장단점을 고려 해봤을 때, 단일 테이블 전략의 단점인 null값이 들어가는게 현재 우리 서비스에서는 null값으로 들어가는 컬럼이 적다고 판단 되어서 단일 테이블 전략으로 선택 하게 되었다.
문제
상황
서비스 회원가입 플로우가 1차 : 소셜 회원가입, 2차 : 추가정보 입력을 받는 순서이다.
즉, 1차로 회원가입이 되어서 DB에 저장이 한번 되고, 2차로 추가정보를 입력 하면서 권한이 부여되고, 기존의 다른 null값들이 수정이 되는 로직이다.
그래서 공통으로 가지는 컬럼들을 1차때 회원가입을 하게 되는 슈퍼 클래스의 필드로 하고,
2차 추가정보 입력 받는 로직에서 권한에 따라서 선생님, 원장님, 학부모 자식 클래스를 만들어 두어서 각각의 권한에 맞는 필드들을 구성해서 슈퍼 클래스를 상속 받는 쪽으로 생각을 했다.
1차 : 소셜 회원가입(생성), 2차 : 권한에 따른 추가 정보 입력(수정)
첫 번째 문제
단일 테이블 전략은 슈퍼 클래스에서 인스턴스를 생성 하지 않고, 자식 클래스에서 생성이 된다.
즉, 1차를 거치지 않고 2차인 자식 클래스에서 DB에 처음으로 생성이 되는 것이다.
첫 번째 접근
슈퍼클래스의 abstract을 지워서 슈퍼클래스에서 인스턴스가 생성이 되도록 해봤다. 물론 이 방법이 데이터 무결성에 어긋나지만 한번 시도를 해보기로 했다. 그래서 1차인 소셜 회원가입이 DB에 한번 저장이 되도록 해보았다. 여기까지는 성공했다.
두 번째 문제
첫 번째 접근을 통해서 1차 회원가입을 하고, 2차로 기존의 null값들을 수정하면 되는데 단일 테이블 전략에서는 자식 클래스가 새로운 인스턴스로 생성이 된다.
즉, 우리는 수정이 필요한데 새로운 객체로 생성이 된다
해결방법
우리 서비스의 회원가입 로직을 바꾸지 않는 이상, 단일 테이블 전략이 맞지 않다고 판단이 되어서
이 전략을 사용 하지 않고 모든 유저가 하나의 테이블을 사용 하되, 권한을 구분하는 컬럼을 추가 해서 하기로 했다.
