상품 정보고시 항목 정의표를 받았다. 카테고리별로 어떤 항목이 필수인지가 적혀 있었다.
Table of contents
Open Table of contents
상황 — 카테고리별 필수 항목표
먼저 눈에 들어온 것은 개수였다.
의류 8개
구두/신발 4개
가방 4개
침구/커튼 6개
가구 6개
영상가전 6개
휴대폰 7개카테고리마다 개수가 다르고 이름도 달랐다.
의류 색상 · 치수 · 제조자 · 제조국 · 세탁방법 · 제조연월 · 품질보증 · A/S
가방 종류 · 소재 · 크기 · 품질보증
휴대폰 KC인증 · 크기/무게 · 가입조건 · 이동통신사 · 가입절차 · 추가부담 · 주요사양세 줄만 놓고 봐도 겹치는 것이 품질보증 하나뿐이다.
그 품질보증조차 모든 카테고리에 있는 것은 아니었다. 공통 항목을 뽑아 놓고 나머지를 붙이는 식으로는 정리가 안 되는 표였다.
품질보증 과 A/S 처럼 뜻이 겹쳐 보이는 이름도 카테고리에 따라 따로 적혀 있었다. 이름이 비슷하다고 같은 항목으로 묶으면 표가 요구한 것과 달라진다.
선택지 — 컬럼으로 만드는 두 길
이것을 표의 컬럼으로 만든다면 두 가지 길이 있었다.
[카테고리마다 테이블] 카테고리 수만큼 테이블
[한 테이블에 다] 컬럼이 수십 개, 대부분 NULL앞쪽은 조회할 때마다 어느 표를 봐야 하는지가 카테고리에 따라 갈린다.
뒤쪽은 표 하나에 컬럼 수십 개가 생기고 각 행에서 대부분이 비어 있다. 의류 상품 행에서 휴대폰 항목 컬럼들은 영영 안 채워진다.
둘 다 곤란한데 더 걸린 것은 카테고리가 늘 때였다. 어느 쪽이든 새 카테고리가 오면 ALTER TABLE 을 해야 한다.
ALTER TABLE 은 배포와 함께 가야 하고 표를 다시 쓰는 동안 products 가 커질수록 오래 걸린다. 카테고리가 느는 일이 흔하다면 그때마다 이 비용을 내게 된다.
조치 — 항목을 데이터로 둔다
항목 자체를 자료로 두는 쪽으로 갔다.
notice_item
category_id
item_name
is_required
product_notice
product_id
item_name
value카테고리가 늘어도 notice_item 에 행만 추가하면 되고 스키마는 그대로다.
얻는 것이 있으면 내주는 것도 있었다.
값이 전부 문자열이 된다
항목별 형식 검증을 DB가 못 한다
"이 상품에 필수 항목이 다 있나"를 SQL로 확인하려면 조인이 필요하다is_required 를 NOT NULL 제약으로 걸 수 없으니 그 검증이 애플리케이션으로 넘어온다.
제조연월이 날짜인지 색상이 목록 안의 값인지도 varchar 하나로는 못 가린다. 무엇을 얻고 무엇을 내주는지가 분명한 교환이라 그대로 받기로 했다.
필수 항목이 다 찼는지 보려면 notice_item 과 product_notice 를 조인해 개수를 맞춰야 한다. 조회 한 번으로 끝나던 확인이 조인 하나를 더 타는 것은 감당할 만했다.
주의 — 이름 안의 조건절
표를 읽다가 항목 이름 하나가 걸렸다.
제조자, 수입품의 경우 수입자를 함께 표기
(병행수입의 경우 병행수입 여부로 대체 가능)이름 안에 조건절이 들어 있어서 이것은 항목명이 아니라 설명문이다.
같은 자리에 적혀 있지만 성격이 다른 것이 섞여 있었다.
[단순 필수] 이 카테고리면 무조건
[조건부 필수] 이 카테고리이고 + 상품이 어떤 조건에 맞으면괄호 안을 안 읽으면 표의 모든 줄이 단순 필수로 보인다.
조건부는 같은 카테고리 안에서도 상품에 따라 갈린다. 가구라도 안전품질표시 대상이 아니면 그 항목이 필요 없다.
is_required 한 칸으로는 이 둘을 못 담는다는 뜻이기도 했다. 참과 거짓 사이에 조건이 맞으면 참이라는 세 번째 상태가 있었다.
같은 이름인데 근거가 달랐다
이런 항목이 하나가 아니었다.
KC 인증 필 유무
(품질경영 및 공산품 안전관리법 상 안전품질표시대상 공산품에 한함)
KC인증 필 유무
(전기용품안전관리법 상 안전인증대상전기용품, 자율안전확인대상 전기용품,
공급자적합성확인대상전기용품에 한함)
KC인증 필 유무
(전파법 상 인증대상상품에 한함, MIC인증 필 혼용 가능)이름은 같은데 근거 법령이 셋 다 다르다.
item_name 으로 키를 잡으면 셋이 하나로 합쳐지고 어느 법령 근거인지가 사라진다. 파는 쪽에 이 항목이 왜 필요한지 설명할 때 근거가 필요하면 합치면 안 된다.
조건부를 시스템에 어떻게 넣을지도 답이 하나가 아니었다.
[전부 필수로] 해당 없는 상품도 입력을 요구 — 셀러가 "해당없음"을 씀
[조건 컬럼 추가] 조건을 데이터로 — 조건이 법령이라 표현이 어려움
[안내만 하고 선택] 필수를 안 걸고 문구로 안내첫째가 가장 단순한데 해당 없는 상품에도 입력을 요구하게 된다. 해당없음이라는 값이 product_notice 에 대량으로 쌓일 것 같았다.
둘째는 조건이 법령이라 is_required 옆에 무엇을 적어야 할지가 안 잡혔다. 셋째는 필수를 안 걸므로 빠뜨린 상품을 나중에 가려낼 방법이 필요해진다.
제약 — 미완인 표
표 맨 위에 이런 줄이 있었다.
* 상이한 카테고리의 경우 차주 월요일 보완하여 재공유 예정아직 다 정해지지 않은 표를 받은 것이다.
다 정해지기를 기다리면 일정이 밀리고 미완인 채로 시작하면 나중에 항목이 늘거나 바뀐다. 항목을 자료로 두기로 한 덕에 뒤쪽을 골라도 행 추가와 수정으로 끝난다.
컬럼으로 만들었으면 재공유될 때마다 스키마를 바꿔야 했다. 표가 미완이라는 사실이 구조를 고르는 데 한몫한 셈이다.
받은 표를 그대로 notice_item 에 넣어 두고 다음 판이 오면 차이만 반영하기로 했다. 지금 판이 어느 시점 것인지를 함께 적어 두어야 다음 판과 대조할 수 있다.
아직 답이 안 난 것도 남는다.
조건부 필수를 어디까지 시스템이 판단할 것인가
법령 근거를 화면에 보여줄 것인가
카테고리가 세분화되면 상위 카테고리 항목을 물려받을 것인가마지막이 특히 걸린다. 가전이 여러 개로 나뉘어 있는데 공통 항목이 겹치고 물려받게 두면 중복은 주는 대신 예외를 적기 어려워진다.
정리
- 카테고리마다 필수 항목의 개수와 이름이 다르다
- 공통 항목을 뽑아 나머지를 붙이는 식으로는 정리가 안 된다
- 컬럼으로 만들면 대부분의 컬럼이 비고 카테고리가 늘 때마다
ALTER TABLE을 한다 - 항목을 자료로 두면
notice_item에 행 추가로 끝난다 - 대신 형식 검증과 필수 검증이 애플리케이션으로 온다
- 항목 이름 안에 조건절이 들어 있는 것들이 있다
- 단순 필수와 조건부 필수가 표의 같은 자리에 적혀 있다
- 같은 이름인데 근거 법령이 다른 항목이 여럿이다
item_name으로 합치면 그 근거가 사라진다- 미완인 표라는 사실이 구조를 고르는 데 한몫했다