해외몰 DDL 의 상품 테이블 TB_PRD_PRD_MST 에 국내 쇼핑몰에는 없는 컬럼이 몇 개 있었다. hs_code(수출입상품번호)와 tax_type(과세유형)과 adult_product_yn(성인상품여부)이었고, 국가별 판매 여부를 담는 TB_PRD_SALE_NATION 도 따로 있었다.
Table of contents
Open Table of contents
배경 — 법적 요건이 스키마에 남긴 자리
hs_code 는 세관이 관세율을 정할 때 보는 국제 분류 코드다. WCO 공식 문서에 따르면 HS 는 여섯 자리 코드로 5,000 개 넘는 품목군을 나누고 200 개 넘는 나라가 관세의 기준으로 쓴다. 국내 판매만 하면 필요 없지만 국경을 넘는 순간 없으면 통관이 안 된다.
이 값은 상품마다 하나로 정해지므로 TB_PRD_PRD_MST 의 컬럼이 맞다. 법적 요건이 스키마에 자리를 갖는 형태였다.
나라마다 달라지는 것
같은 상품인데 나라마다 갈리는 것이 있었다. 이 스키마에서는 그 나라에 파는지 여부가 그것이고, TB_PRD_SALE_NATION 이 prd_prd_mst_no 와 nation_cd 를 기본 키로 삼아 use_yn 하나를 든다.
이것을 상품 컬럼으로 넣으면 나라를 추가할 때마다 sale_us_yn·sale_jp_yn 식으로 컬럼이 는다. 그래서 상품 하나가 국가마다 행을 갖는 별도 테이블로 빠져 있었다. 가격과 배송은 TB_PRD_SALE_INFO·TB_PRD_DLV_INFO 로 상품 단위이고, 나라 단위 설정은 사이트가 TB_SYS_SITE_MST.nation_cd 로 나라마다 하나씩 있어 그쪽에 붙는다.
판단 기준 — 무엇에 대해 하나인가
컬럼으로 둘지 테이블로 뺄지는 무엇에 대해 값이 하나인가로 갈렸다. 상품에 대해 하나면 컬럼이고 상품과 국가의 조합에 대해 하나면 테이블이다.
실무에서 헷갈리는 것은 지금은 나라가 하나뿐인 상황이다. 나라가 늘 것이 확실하면 처음부터 축으로 만들고 확실하지 않으면 컬럼으로 두되 옮기는 비용이 예측되게 해 둔다.
성격과 정책을 나눈다
tax_type 이 상품 컬럼인 것이 처음에는 이상해 보였는데 그것은 상품 자체의 분류였다. 과세 대상인지 면세인지를 상품이 갖고, 세율 값은 이 DDL 어디에도 없어서 결제 단계가 나라에 따라 정하는 몫이다.
adult_product_yn 도 같은 구조로 상품에는 표시만 두고 그것을 어떻게 취급할지는 나라 쪽 규칙에 있다. 상품이 세율 값을 직접 들고 있으면 세율이 바뀔 때 전 상품을 고쳐야 하므로 자주 바뀌는 쪽을 분리한 것이다.
주의 — 나눈 뒤 늘어난 실수 자리
이렇게 나누면 조회에 TB_PRD_SALE_NATION 조인이 붙고 어느 나라를 보는지를 매번 지정해야 한다. nation_cd 조건을 빠뜨리면 상품 하나가 나라 수만큼 중복돼 나온다.
그 실수를 한 자리로 모으는 데는 두 가지 방법이 있었다. 세션의 국가를 기본으로 거는 DB 뷰를 두는 것과, 코드 쪽에 findByNation($nationCd) 하나를 두고 관리 화면이 그것만 쓰게 하는 것이다. 뒤쪽을 골랐다. 이유는 MySQL 5.7 매뉴얼의 CREATE VIEW 절이 뷰의 SELECT 에서 사용자 변수를 참조할 수 없다고 못 박고 있어서, 세션 국가를 뷰 안에 넣을 길이 없어서다. 나누면 실수가 생길 자리가 늘어나므로 그 자리를 하나로 막아 두는 편이 낫다.
정리
- 해외 판매에서는 법적 요건이
hs_code같은 스키마 컬럼이 된다 - 컬럼과 테이블은 무엇에 대해 값이 하나인가로 가른다
- 상품에 하나면 컬럼이고 상품과 국가에 하나면
TB_PRD_SALE_NATION같은 테이블이다 - 나라가 늘 것이 확실하면 처음부터 축으로 만든다
- 상품은
tax_type같은 성격만 갖고 정책은 나라 쪽에 둔다 - 바뀌는 주기가 다르면 저장하는 곳도 나눈다
- 나누면 조회에
nation_cd조건이 늘고 빠뜨리면 행이 중복된다 - 그 실수 자리를 조회 메서드 하나로 모아 막는다