쿠폰 테이블을 왜 두 개로 나누었나?

목표 D-day : 38 일

ERD를 작성하면서 쿠폰 테이블을 두 개로 나눈 이유를 정리해보려고 합니다.

쿠폰 ERD

두 개로 나눈 구체적인 이유

먼저, 쿠폰 정보와 발행된 쿠폰을 분리하는 것이 유연하고 확정성있는 설계가 가능합니다.

쿠폰을 단일 테이블로 관리하는 경우 단순한 데이터 구조로 RDBMS의 Join없이 조회가 가능한 것이 장점입니다.

Q.테이블 관계에서 Join없이 조회가 가능하다는 것이 장점인 이유

관계형 데이터베이스는 중복된 데이터를 저장하지 않기 위해서 테이블을 나누어 관리합니다. 정규화라고도 합니다.

데이터 무결성을 위해 A,B,C 테이블로 나누어 관리하는 경우 하나의 전체 데이터를 조회하기 위해 1:1, 1:N 관계의 테이블을 JOIN을 통해 가져오는 연산이 필요합니다.

데이터가 누적되어 테이블의 크기나 인덱스에 따라 성능 저하가 발생할 수 있기 때문입니다.

Q.단순한 데이터 구조가 장점인 이유

단일 테이블은 데이터 구조가 하나이므로 조회하는 SQL도 매우 간단해지빈다.

테이블 간의 복잡한 JOIN을 사용하지 않기 때문입니다. 복잡한 연관 관계를 신경쓰지 않아도 되므로 정규화된 테이블로 개발할 때보다 개발 속도가 초기에는 빨라 질 수 있습니다.

단일 테이블을 선택하지 않은 이유

1. 불필요한 공간 차지하게 됩니다. 쿠폰 정보만 있고 발행되지 않은 쿠폰의 경우, 남은 필드가 불필요한 공간을 차지하게 됩니다.
2. 쿠폰 정보 변경이 어렵습니다. 데이터가 많아진후 쿠폰 정보가 변경되거나 추가되는 경우, 많은 레코드의 필드 수정을 발생시키게 됩니다.
3. 인덱스 관리가 어렵습니다.쿠폰 정보를 조회하기 위한 인덱스와 발행된 쿠폰을 조회하기 위한 인덱스가 공존하게 되므로, 인덱스가 복잡해지고 많아져서 유지보수가 어렵습니다.
4. 쓰기 성능 저하가 발생합니다. 쿠폰 정보와 발행된 쿠폰 인덱스가 같이 있다보니 인덱스가 많아지면서 쓰기 성능과 수정 성능이 저하될 수 있습니다.

테이블 분리의 장점

1. 최적화된 인덱스 사용이 가능합니다. 테이블별로 최적화된 인덱스를 사용할 수 있으며, 테이블이 커진다면 단일 테이블보다 인덱스 유지보수가 단일 테이블보다 쉽습니다.
2. 독립적인 테이블 정보 수정이 가능합니다.만약 쿠폰 정보가 변경되어도 발행된 쿠폰은 스키마 수정이 필요 없습니다.

두 개로 나눈 테이블이 단일 테이블보다 인덱스 관리가 쉽다고 생각한 구체적인 이유

단일 테이블에서는 쿠폰 정보만 필요한 경우에 사용될 수 있는 인덱스와 사용자가 가지고 있는 쿠폰을 조회하는 데 필요한 인덱스가 모두 필요합니다.

• 예: 판매자가 제공하는 쿠폰을 조회하려면 인덱스 A는 회사 고유번호, 시작일, 종료일이 필요합니다. 구매자가 물품을 구매하려고 할 때 자신의 쿠폰을 조회하려면 인덱스 B는 자신의 고유번호, 시작일, 종료일이 필요합니다.
• 이렇게 단일 테이블로 관리하면 판매자가 조회할 때 필요한 인덱스와 구매자가 조회할 때 필요한 인덱스가 공존하게 됩니다. 지금 당장은 칼럼 수가 적어 인덱스가 많이 없지만, 다양한 검색 조건에 따라 필요한 인덱스가 증가하게 됩니다. 이후 슬로우 쿼리가 발견되어 인덱스를 추가해 성능 개선이 필요할 때, 인덱스가 많아질수록 쿠폰 테이블에 쓰기 성능은 저하될 수 있어 인덱스 추가가 어려워지기 때문에 유지보수하기 어렵다고 생각했습니다.

스키마 변경 시 어떤 식으로 유연하게 대응할 수 있다고 생각한 구체적인 이유

이후 쿠폰 정책이 변경되어 쿠폰 정보에 추가로 나이 제한, 사용 시간 제한, 할인 한도 등이 추가될 경우를 가정해본다면

• 단일 테이블일 경우: 쿠폰 정보만 변경하고 싶어도 발행된 쿠폰까지 영향을 주게 됩니다.
• 테이블 분리의 경우: 쿠폰 정보 테이블을 변경해도 발행된 쿠폰 테이블은 영향을 받지 않습니다. 테이블의 필드 추가나 변경이 발생해도 영향을 받는 테이블이 작아져 단일 테이블보다 스키마를 변경하기 유연합니다.