[마켓 브릿지 프로젝트] 카테고리 기능 구현 1. MySQL 계층 구조

이 프로젝트의 처음 시작은 "쿠팡"을 모티브로 한 프로젝트였고, 막연히 쿠팡의 많은 기능을 참고해보자! 였다.

왜 쿠팡으로 잡았냐면, 전형적인 오픈마켓 플랫폼. 즉, 여러 판매자가 아주 다양한 상품을 자유롭게 판매하고 있기 때문이다.

-> 확장성이 매우 중요한 작업이 될 것 같았고, 그로 인해 신경써야할 부분을 공부해보고 싶었기 때문이다.

 

 

자, 이제 내가 맡은 카테고리 기능 구현에 대해 기록해보고자 한다.

1. 쿠팡 카테고리 살펴보기

A. 쿠팡 카테고리 특이점 1. "패션의류/잡화" 카테고리는 최상위 뎁스가 아닐 것이다.

크롤링 할때 유심히 살펴보았는데 쿠팡은 왠지 처음엔 패션의류/잡화 카테고리가 메인이었던 거 같다.

바꿔 말하자면, 가장 큰 대분류가 예전에는 여성패션,남성패션 ... 부터 시작이었던거 같다.

왜냐하면 패션의류/잡화는 사실상 화면에만 표시해둔 격이지, 실제로 디비에 존재하는 지는 의문인 모습이 보인다.

이런식으로 여성 패션에 들어가보면 쿠팡 홈 > 여성패션 으로 바로 접근하는 것을 볼 수가 있다.

F12로 살펴보니 카테고리 코드도 존재하지 않는 듯하다.

여튼 각설하고, 그래서 데이터 수집도 담당한 나는 수집하기 번거롭지 않게 우리의 프로젝트에는 초창기 쿠팡 모습(일 것이라 추측되는)과 마찬가지로 패션쪽은 여성패션, 남성패션 .. 등등을 가장 상위 뎁스로 잡았다.

 

B. 쿠팡 카테고리 특이점 2. 최하위 카테고리 깊이가 카테고리 별로 제각각이다.

일례로 여성패션 > 가방/잡화 카테고리를 살펴보면 모자,두건,귀마개는 3뎁스가 최하위인데, 가방, 여행가방/소품 등등은 그 아래의 뎁스까지 존재하는 것을 알 수가 있다.

👉🏻  여기서부터 카테고리의 확장성을 고려해야겠다고 생각했다.

 

2. 마켓브릿지 카테고리 ERD 설계 - MySQL

📌 카테고리 구현 조건
1. 최하위 뎁스를 추가하는 상황을 고려할 것
2. 하위 뎁스의 정보만 가지고도 상위 뎁스들을 알 수 있을 것

A. 고려한 방법론 후보

1️⃣ 대분류, 중분류, 소분류 각각 테이블을 만든다.

- 각각 테이블을 만들어서, 대>중>소 => 일대다, 일대다, 일대다 관계로 만들어 놓는 방법을 생각했다.

상품과의 관계는 이렇게 각 카테고리의 id값을 포함시켜 놓는 것.

* 장점 1. 설계가 간단하다.

*한계점 1. 소분류 하위 뎁스를 추가하려면 테이블을 최종_소분류 테이블, 최최종_소분류 테이블 .. 이런 과정이 생길 것이다.

반대로 없어진다면? -> 디비 테이블을 삭제한다니 너무 아찔하다

한계점 2. 테이블 추가 뿐만이 아니라 product 테이블도 수정을 해야한다. 최종_소분류 테이블 id 추가 이런식으로.. -> 매우매우 위험

 

2️⃣ (최종 결정) 계층형 카테고리 구조

실제 적용한 ERD의 모습이다.

쉽게 생각하면 이런식의 구조가 되는 것이다.

최상위 카테고리의 부모 id는 null값으로 세팅해두었다.

*장점 1. 확장성이 뛰어나다. -> 유지보수가 편해진다.

*단점 1. 재귀조회를 해야하므로 (그럴 일은 적겠지만) 카테고리 데이터가 방대해질수록 비효율적이다.

*단점 2. 마찬가지로 재귀조회라서 상품데이터와 연관지어서 조회시 시간이 오래 걸린다. -> 이 부분은 아직도 고민중이다.

 

B. 재귀 조회 SQL문

select c1.category_id as category_id,c2.category_id as parent_id,c1.level,c1.name from category c1 
left join category c2 on c2.category_id=c1.parent_id and c1.category_id != c1.parent_id
-- where c1.parent_id = 1 
order by  c2.category_id asc, c1.category_id asc;

조회할 때는 left join을 사용해서 재귀적으로 조회를 하면 된다.

특정 부모의 하위 카테고리를 보고싶다면 where절을 하나 추가해주면 된다.

*어려웠던 점 1. 오라클은 계층 구조일 때 질의문이 따로 존재하는데, MySQL에는 없어서 한땀 한땀 만들어줘야한다.

오라클에서는

START WITH
CONNECT BY PRIOR
ORDER SIBLINGS BY

이런식으로 계층구조 질의문의 존재한다.

왜 오라클 안쓰고 MySQL을 선택해서 이 고생을 했냐 물으신다면, 우리는 배포까지 할 작정이었기 때문에 맘편히 무료인 MySQL을 택했다.

가난한 취준생은 어쩔수가 없다ㅠ 이런 불편쯤은 감내해야쥐..

 

다음 포스팅은 이제 코드 단으로 올라가보도록 하겠다.