[마켓 브릿지 프로젝트] 상품 옵션 기능 구현 1. 확장성있는 DB 설계

👉🏻 오픈 마켓 플랫폼

: 상품을 구매 또는 판매할 수 있는 기회가 개방되어 있는 온라인 전자상거래 플랫폼을 일컫는다. 서비스 운영사가 거래에 관여하지 않고 플랫폼만 제공하는 중개자의 역할만 한다는 점에서 다른 전자상거래 형태와 구분된다.

오픈 마켓 플랫폼의 특성상 판매자가 원하는 대로 상품을 판매할 수 있어야한다.

즉, 상품의 옵션, 이미지, 태그 등등 높은 자유도를 제공해야한다는 것이다.

이런 특성 때문에 오픈 마켓 플랫폼 프로젝트가 하고 싶었기도 했다.

 

따라서, DB 설계 시 확장성 측면을 매우 중요하게 생각했다.

1. 옵션 DB ERD 설계

실제 프로젝트에서 구현한 상품-상품옵션 부분 ERD이다.

 1️⃣ 상품과 옵션은 다대다 관계이다.

처음에는 상품과 옵션을 N:M의 관계로만 생각했다.

상품도 여러 옵션을 가지고 있고, 옵션도 여러 상품을 가지고 있다.

관계형 테이블의 다대다 관계를 구현할 때는 join 테이블을 하나 만들어서 관리하기 때문에, 우선 product, options, product_option(조인테이블) 이렇게 구성했다.

다대다 관계의 테이블은 조인 테이블이 없이는 구현이 불가능하다.

이런식으로 가운데의 조인 테이블을 둬서 상품의 옵션을 조회하게 된다.

문제점 발생 1. 옵션 데이터의 관리가 어렵다.

• 데이터의 중복 발생 위험

옵션만 생각했을 때, L, XL 식으로 의류 사이즈를 표현하기도 하지만 36, 37 처럼 숫자로 표기하기도 한다.

숫자의 경우, 미국 신발 사이즈, 중국 신발 사이즈 저럼 36,37와 같은 숫자를 쓰지만, 그 쓰임은 다르다.

• 데이터 조회 시 분류 어려움

반대로 옵션 별 상품의 종류라든지, 옵션 별 상품의 수량이라든지 상품의 재고 관리, 매출 관리에 필요한 데이터 조회 시 분류가 어렵다.

위에서 단점과 이어지는데, 옵션 데이터 하나하나가 어디에 속한 것인지 전체 상품 조회 후에 분류하는 작업을 통해서만 원하는 데이터를 조회할 수 있을 것이다.

아래는 실제 쿠팡 여성의류 > 상의 만봐도 이렇게 같은 의미의 옵션이더라도 다양하게 구성되어있다. => 옵션데이터의 분류 필요

 

즉, 데이터의 관리가 어려운 설계라 조회 시에 효율이 굉장히 안 좋을 것이라고 판단했다.

 

2️⃣ 옵션 카테고리 table로 옵션 데이터를 분류한다.

 

옵션 테이블에 옵션 카테고리 컬럼을 하나 추가하는 방법이 제일 간단하다.

이렇게 구성을 하는 것도 좋다.

그러나 데이터에는 생각보다 옵션 카테고리가 다양하다. (추가가 많다)

아직 초기 단계에서 생각할 방법은 아니겠지만, 크롤링을 해보니 생각보다 판매자 쪽의 사용자가 아주 다양한 옵션 카테고리를 사용한다.

이런식으로 판매자가 옵션명을 자유롭게 설정하고, 추가하는 구조였다.

나중에는 옵션 데이터를 가지고 데이터 분석을 한다든지 하는 먼 미래를 생각해보았다.

옵션 카테고리가 따로 있으면 굳이 옵션 데이터의 로우가 많은데, 그 많은 데이터를 전체 조회하지 않아도 될 것이다.

또, 그럴 일은 없어야하겠지만, 옵션 카테고리에 다른 필드를 추가하는 등의 특성 부여를 한다든지하는 상황말이다.

확장성만을 생각했다

그래서 이런식으로 옵션 카테고리 테이블을 따로 둬서 관리를 해서 옵션 카테고리만 따로 조회하고, 관리할 수 있게 구성하였다.

옵션 추가 시에 옵션 카테고리가 아무리 다양해져도 db의 스키마가 바뀔 일은 없다.

또한, 추가 시에 전체 범위를 볼 필요없이 해당하는 특정 카테고리로 필터링하여 효율적으로 조회할 수 있다.

옵션 별 재고 현황, 상품 종류를 조회할 때도 옵션 데이터가 1차적으로 분류가 되어있기 때문에 조회가 용이해진다.

 

2. 상품 Table ERD

어떤 티셔츠가 있다고 치자.

색상 옵션 : 빨강, 노랑, 초록

사이즈 옵션 : S, M, L, XL

이렇게 옵션이 구성되어있다고 생각하면 3*4 =12개의 상품이 따로따로 존재하는 것이다.

재고, 할인 프로모션 등등 다 따로 관리가 되는 것이다.

처음에는 당연히 상품-옵션 조인테이블에서 관리를 해야한다고 생각했다

1️⃣ 옵션이 없는 상품이 있을 수도 있는 상황

-> 상품 옵션 조인 테이블에 두면 옵션 이름을 null값으로 넣든지 빈값으로 두어야하는 문제

2️⃣ 상품-옵션 조인 테이블에 너무 많은 정보

-> 조인 테이블에 너무 많은 정보가 담겨 있어서 다른 재고 관리 테이블, 주문테이블 등등에서 조인할 때 문제가 될 수 있다.

 

그래서 상품 테이블에서 재고, 할인율 등등을 관리하도록 배치했고, 어차피 상품 등록 시에 옵션 테이블과 연관관계를 맵핑해줄 것이기 때문에 상관이 없을 것이라 판단했다.

 

이런 맥락으로 태그, 이미지도 같은 구조로 설계하였다