상태 컬럼으로 센 잘못된 분류

주문 상태별 건수를 내니 합이 전체와 맞아떨어져서 문제가 없어 보였다. 그런데 부분 취소된 주문이 몇 건이냐는 질문을 받고 답을 못 했다.

Open Table of contents

상태가 못 담는 것

전체 취소는 주문 상태로 표현되는데 부분 취소는 주문 상태가 안 바뀌고 항목 쪽에만 표시되고 있었다. 항목을 기준으로 다시 세니 3천여 건이 부분 취소에 해당했다.

그 건들은 주문 상태로 세면 결제 완료나 배송 완료에 섞여 있었다. 상태 컬럼 하나로는 담지 못하는 상태가 있고 그것을 모르면 집계가 조용히 틀린다.

그래서 무엇을 세는지를 네 가지로 나눠 정의하고 각각 다른 조회로 만들었다. 결제 완료 주문과 전체 취소 주문과 부분 취소를 포함한 주문과 항목에 취소가 하나도 없는 정상 완료 주문이다.

전에는 취소라고만 하면 전체 취소만 세고 있었는데 정의를 나눈 뒤로는 어느 숫자를 묻는지가 질문 단계에서 분명해졌다.

분류를 조합으로 판정하는 함수를 만들다가 예상에 없던 넷째 경우가 나왔다. 항목이 전부 취소됐는데 주문 상태는 그대로 살아 있는 것이었다.

세어 보니 412건이었고 항목을 취소할 때 주문 상태를 함께 보지 않는 코드가 원인이었다. 전부 취소되면 주문도 취소하도록 고치고 이미 그렇게 된 412건은 정산에 영향이 있어 확인받고 따로 처리했다. 분류하려고 조합을 따지다가 아무도 몰랐던 상태가 드러났다.

판정을 매번 계산하면 조회가 무겁고 저장해 두면 갱신을 빠뜨렸을 때 틀린 값이 남는다. 그래서 통계용으로는 저장하고 화면에서는 그때그때 계산하는 쪽으로 갈랐다.

저장한 값이 맞는지는 매일 계산값과 대조하는 조회를 돌려 확인했다. 화면에도 결제 완료 안에서 정상과 부분 취소와 전 항목 취소를 나눠 보이게 하니 이상한 것이 바로 눈에 띄었다.

부분 취소를 상태값으로 하나 추가할 수도 있었지만 그렇게 하지 않았다. 부분 취소와 배송 완료가 겹치고 거기에 부분 환불까지 겹치면 조합이 곱해져 상태가 수십 개로 늘어난다.

주문의 진행 단계는 기존 상태로 두고 취소 여부는 별도 분류 컬럼으로 뒀다. 축이 여럿인 것을 한 컬럼에 담으려 하면 상태가 폭발하므로 축을 나누면 조합이 곱해져도 각각은 단순하다.