상품 테이블 스키마 변경

개요

기존의 상품관련 테이블 스키마의 한계 때문에 여러 옵션을 추가로 등록할 수도, 이미지를 관리하기도 어려웠다. 그래서 기존의 단일테이블들을 참조관계를 가진 여러 테이블로 분할하고, 떨어질 수 있는 성능은 최대한 최적화 해주었다.

CategoryTable

기존에는 카테고리가 Depth 2까지 있는 상태였지만, 단일 테이블로 구분되고 있었습니다. 이는 나중에 추가 카테고리가 생기거나 카테고리 이름을 변경할 때 확장성이 떨어진다는 생각을 하여 대중소 카테고리 분류를 만들기로 변경하였습니다. 대중소 카테고리의 경우 현재 없는 Depth 3까지 고려한 것이고, 각 데이터들을 독립적이면서도 유기적으로 연결시키기 위한 설계입니다.

카테고리 테이블을 Parent_id 칼럼을 두어 하나의 테이블로 만들기 보다는 테이블을 나누어서 데이터의 일관성을 최대한 취하고 싶었고, 설계된 부모-자식 관계가 조금 더 직관적인 느낌을 유지하고 싶었습니다. 다만 이런 설계는 카테고리를 조회할 때마다 JOIN연산이 일어난다는 단점이 있습니다. 그래서 VIEW를 만들어 JOIN연산이 일어나지 않도록 변경하였습니다. VIEW는 업데이트가 되진 않지만, 카테고리는 원래 추가,수정,삭제가 비교적 빈번히 일어나지 않기 때문에 이러한 결정을 했습니다.

CREATE VIEW all_category_view AS
SELECT ac.id AS all_category_id, lc.name AS large_category_name, 
			 mc.name AS medium_category_name
FROM all_category ac
INNER JOIN large_category lc ON ac.lg_ct_id = lc.id
INNER JOIN medium_category mc ON ac.md_ct_id = mc.id;

Product Table

기존에는 option을 위한 테이블이 별도로 없었으며 이미지 테이블에서 옵션을 관리하는 방향이었습니다. 시스템을 쉽게 만들기 위한 설계였고, 확장성을 가진 방향으로 아래와 같이 정리해보았습니다.

1. option을 고려하고 확장성을 가질 것.
2. detail 페이지의 내용을 HTML로 입력하게 변경하였기 때문에 데이터 타입을 TEXT로 변경할 것.
3. option의 이미지는 1가지로 고정할 것이기 때문에 option 테이블에 image_url을 둘 것

Index 설정

ALTER TABLE product_option ADD INDEX product_id_index (product_id);
ALTER TABLE product_images ADD INDEX product_id_index (product_id);

product_option테이블과 상기 product_images) 테이블은 모두 product_Info 테이블의 pk(id)를 fk로 가지며, 데이터 조회시 대부분 join연산이 일어납니다. 따라서 option과 images 테이블에서 fk(product_id)를 인덱스설정 해주면, 이점이 있을 것이라 생각했습니다. 또한 인덱스 설정은 조회성능에 이점이 있고, 수정, 삭제, 추가에는 좋지 않습니다. 쇼핑몰 특성상 유저의 사용감이 관리(수정,삭제)보다 중요하므로 해당 데이터들은 인덱스 설정을 하는 것이 좋다고 판단하였습니다.

마무리

전부 좋은 판단인지는 모르겠으나 나름의 이유를 생각해서 재설계를 진행하였습니다. 보시고 질문이나 아니면 부족한 부분을 말씀해주신다면 너무 감사드릴것 같습니다.