정산 매칭에서 못 푼 잔여 몇 건이 있었고 기록에는 한 주문 번호에 동일 옵션 항목이 여럿이라 특정이 불가하다고 남아 있었다. 앞서 여러 방법을 시도했고 전부 안 됐다는 뜻이었다.
Table of contents
Open Table of contents
두 개의 연동 키
이 채널의 연동 컬럼을 보니 order_no와 bundle_no 둘이었다. settlement:match 커맨드는 order_no로만 찾고 있었다.
두 키로 각각 항목 수를 세어 봤는데 order_no는 한 값에 최대 수십 건이 달려 있어서 어느 항목인지 고를 수 없었다. bundle_no로 세니 어느 값에도 항목이 하나씩만 달려 있었다.
조치 — 옆 컬럼 하나로 풀린 것
bundle_no로 매칭하면 정확히 하나가 나오고 잔여 전부가 그랬다. 대상 항목들도 전부 정상 상태였고 수정한 뒤 확인 커맨드를 돌리니 잔여가 전부 해소됐다.
앞서 시도한 것들을 보면 식별자를 디코딩하거나 다른 경로로 특정하려 한 흔적이 있었다. 정작 옆 컬럼을 세어 보지 않은 채 order_no로 다건이니 특정 불가라는 데서 멈춘 것이었다.
판단 기준 — 카디널리티 확인의 비용
그래서 특정 불가 판정이 나오면 포기하기 전에 다른 키의 카디널리티를 반드시 먼저 세어 보기로 했다. 연동 테이블에는 대개 외부 식별자가 여러 개 있고 채널마다 어느 것이 유일한지가 다르다.
확인 비용은 조회 하나다. GROUP BY 키로 세고 HAVING COUNT(*) > 1만 남기면 되고 결과가 0건이면 그 키는 유일하다. 특정 불가로 몇 시간 헤매기 전에 이 조회를 몇 개 키에 돌리는 것이 훨씬 싸다.
두 가지 방법이 있었는데 잔여를 손으로 고치고 끝내는 것과 settlement:match의 매칭키를 채널에 따라 고르도록 바꾸는 것이다. 뒤쪽을 골랐다. 이유는 안 고치면 다음 정산에 또 같은 잔여가 쌓여서다. 대신 채널별 키 설정을 하나 더 관리하는 것을 감수했다.
주의 — 매칭용 키와 판별용 키
여기서 조심할 것이 하나 나왔다. bundle_no가 매칭에 좋다고 모든 용도에 좋은 것은 아니었다.
이 채널은 분리 배송이 있어서 한 주문이 여러 묶음으로 나뉘고 같은 주문에 다른 bundle_no가 붙는다. 중복 판별에 bundle_no를 쓰면 같은 주문인데 다른 건으로 세어진다. 매칭에는 유일한 bundle_no를 쓰고 중복 판별에는 같은 주문을 묶어야 하므로 order_no를 쓴다. 용도가 다르면 키도 다르다.
교훈 — 특정 불가라는 판정
이 건에서 정리된 것이 셋이다. 연동 테이블에는 외부 식별자가 여러 개 있고 어느 것이 유일한지는 채널마다 다르며 매칭용 키와 판별용 키가 다를 수 있다.
특정 불가라는 판정은 그 키로 특정이 불가하다는 뜻이지 특정이 불가하다는 뜻이 아니다. 판정을 적을 때 어느 키로 시도했는지를 함께 적으면 다음 사람이 옆 컬럼을 보게 된다.
정리
- 특정 불가 판정 전에 다른 키의 카디널리티를 센다
- 연동 테이블에는 외부 식별자가 여러 개 있다
- 어느 것이 유일한지는 채널마다 다르다
- 카디널리티 확인은
HAVING COUNT(*) > 1조회 하나이므로 헤매기 전에 돌린다 - 개별 수정으로 끝내지 말고
settlement:match의 매칭키를 고친다 - 매칭용 키와 중복 판별용 키가 다를 수 있다
- 용도가 다르면 키도 다르다
- 판정을 적을 때 어느 키로 시도했는지를 함께 적는다