Skip to content
isdnetworks
Go back

컬럼 하나로 답이 안 나온다

정산에 이미 반영된 금액을 되돌려야 하는지 판단해야 했다. 관련 컬럼이 비어 있어서 미반영으로 끝내려다 멈췄다.

Table of contents

Open Table of contents

컬럼 하나가 배제하지 못하는 것

그 컬럼이 비어 있다는 것은 그 경로로 가지 않았다는 뜻이다. 다른 경로가 없다는 보장은 아무 데도 없었다.

관련 테이블이 몇 개인지를 메타데이터로 열거해 봤다. 일반 정산과 조기 정산과 원장과 조기 정산의 주문 연결까지 넷이 나왔다.

참조가 한 방향뿐이었다

정산 테이블에서 이 주문을 찾으려고 컬럼을 봤는데 주문을 가리키는 참조가 없었다. 정산 테이블은 정산 단위로 만들어져 있고 어느 주문에서 왔는지는 적혀 있지 않았다.

연결은 주문 쪽에서 정산을 가리키는 방향으로만 있었다. 한 방향뿐이면 이 정산에 이 주문이 들어갔냐는 질문을 정산 쪽에서 물을 수 없다.

컬럼이 아닌 별도 테이블

그래서 주문 쪽에서 갈 수 있는 경로를 전부 찾았다. 일반 정산과 보상 정산은 각각 컬럼으로 연결돼 있었다.

세 번째인 조기 정산은 컬럼이 아니라 별도 연결 테이블에 주문 식별자로 들어 있었다. 주문 레코드만 열어 보면 그 경로는 보이지 않는다.

셋을 다 조회한 결과

세 경로를 각각 조회해 표로 만들었더니 앞의 둘은 비어 있고 세 번째에 행이 있었다. 이번 건이 조기 환불 유형이라 그 경로로 잡혀 있었다.

컬럼 하나만 보고 미반영이라고 판단했으면 이미 정산된 금액을 다시 처리할 뻔했다. 판정 규칙을 셋 중 하나라도 값이나 행이 있으면 중단으로 정하고 절차에 적었다.

질문 하나에 답을 찾는 방법이 여럿

왜 이런 구조가 됐는지 짐작해 보면 정산 방식이 하나씩 추가되면서 연결 방식도 그때마다 달라진 것으로 보인다. 처음에는 컬럼 하나였고 다음 유형에서 컬럼이 하나 더 붙었으며 세 번째는 다대다라 별도 테이블이 됐다.

각각은 그 시점에 합리적인 선택이었을 것이다. 문제는 이 주문이 정산됐냐는 질문 하나에 답을 찾는 방법이 셋이 됐다는 점이고 그러면 반드시 하나를 빠뜨린다.

정리


Share this post on:

Previous Post
일곱 달 요청과 한 달치 로그
Next Post
들여왔다고 켜진 게 아니다