매핑표를 먼저 완성한다

옛 시스템의 코드 체계를 새 형식으로 옮기는 작업이었고 init.sql은 끝낸 상태였다. 다음은 data.sql인데 값들이 영문 약어로 들어 있어서 새 코드 형식으로 바꿔야 했다.

Open Table of contents

판단 기준 — 하나씩 바꾸지 않은 이유

두 가지 방법이 있었는데 약어를 sed로 찾아 하나씩 바꾸는 것과 mapping.tsv를 먼저 완성하는 것이다. 앞쪽은 세 가지가 걸렸다. 같은 약어가 여러 컬럼에 나올 수 있고 어느 코드 그룹에 속하는지가 컬럼마다 다르며 놓친 것이 있는지를 알 수 없다.

셋 중 마지막이 결정적이었다. 뒤쪽을 골랐다. 이유는 하나씩 바꾸면 끝났는지를 판정할 방법이 없어서다. 대신 변환에 손대기 전에 표를 채우는 시간이 먼저 드는 것을 감수했다.

각 컬럼이 어느 코드 그룹에 속하는지를 확인하고 값별 대응을 적었다. category_type과 sale_status와 display_status와 brand_type처럼 컬럼 단위로 줄을 나눴다.

여기에 COUNT(*) 건수도 같이 적었다. 변환 후에 개수를 대조할 수 있으므로 표의 각 줄이 그대로 검증 항목이 된다.

inquiry_type에서 걸렸다. 넷 중 하나만 대응이 있고 나머지 셋에 대응하는 하위 코드가 없었으며 가장 가까운 것 하나가 셋을 다 포괄하는 성격이었다.

셋을 하나로 통합하기로 하되 그냥 넘기지 않고 매핑표에 주의로 적었다. 도매와 부품과 서비스 구분이 사라지기 때문이다. 되돌릴 수 없는 변환은 그 사실을 남겨야 나중에 왜 세 종류가 하나가 됐는지를 그 줄이 답한다.

banner_type은 넷이 각각 대응됐는데 번호가 연속이 아니었다. 중간 두 자리가 비어 있었지만 억지로 순서대로 맞추지 않고 의미가 맞는 것으로 붙였다.

inquiry_type과 banner_type 매핑은 1대1 대응이 문서로 확정된 것이 아니라 의미를 보고 판단한 것이었다. 그래서 매핑표에 이 둘은 대응이 불가해 합리적 추정을 적용했다고 명시했다.

나머지는 컬럼 이름과 코드 그룹 이름이 명확히 대응해서 확정으로 뒀다. 확정된 것과 추정한 것을 나눠 적지 않으면 표 전체가 같은 신뢰도로 읽히고 나중에 어디를 다시 봐야 하는지 알 수 없다.

작업 순서는 init.sql의 코드 정의를 새 형식으로 변환하고 그 결과로 mapping.tsv를 완성한 뒤 data.sql을 일괄 변환하는 셋으로 잡았다. 새 코드 체계가 확정돼야 매핑 대상이 생기므로 첫 단계가 먼저다.

두 번째를 건너뛰고 세 번째로 가면 변환하다가 이것을 무엇으로 바꿀지를 계속 만나고 그때마다 멈춰 판단하게 된다. 매핑표가 있으면 표의 각 줄이 sed 치환 하나가 되어 변환이 기계적이 되고 적어 둔 건수로 변환 후 개수까지 대조된다.