공통 출발점
결제 공통 속성과 타입별 속성을 어디에 둘지에 따라 병합 비용이 달라집니다.
핵심은
한 번에 조회할 때의 단순함
과
중복·희소 컬럼 관리
사이의 선택입니다.
Payment id, amount, type
CardPayment payment_id, card_number, installment
BankPayment payment_id, bank_code, account
비교 축
전략 1. 단일 테이블
JOIN 제거
전략 2. 타입별 분리
NULL 제거
전략 3. 조인 유지
정규화 유지
구조
Payment id, amount, type card_number, installment bank_code, account
CardPayment id, amount, card_number... BankPayment id, amount, bank_code...
Payment id, amount, type CardPayment / BankPayment payment_id + 개별 속성
읽기 시 이점
전체 결제를
한 테이블
에서 바로 조회하므로 쿼리가 가장 단순합니다.
각 결제 타입이 자기 컬럼만 가져서 저장 구조가 깔끔하고 타입별 처리에 유리합니다.
공통 속성은 한곳에 두고 개별 속성만 확장해
일관성과 확장성
을 지키기 쉽습니다.
감수할 비용
`CARD`가 아니면 카드 컬럼이 비고, `BANK`가 아니면 계좌 컬럼이 비어
NULL과 공간 낭비
가 커집니다.
전체 결제 목록을 보려면 여러 테이블을
UNION
해야 해서 통합 조회가 번거롭습니다.
카드·계좌 상세를 함께 보려면 결국
JOIN
이 필요하므로 읽기 경로가 길어집니다.
적합한 경우
서브타입 수가 적고 컬럼 구성이 비슷하며, 조회 단순화가 가장 중요할 때
타입별 차이가 크고, 전체보다는 각 타입을 따로 다루는 업무가 많을 때
공통 규칙을 유지하면서 새 서브타입이 늘어날 가능성까지 고려해야 할 때