실제로 읽히던 두 컬럼

판매가를 직접 고쳐야 했는데 연관 테이블이 다섯 개나 걸려 있었다. 연동 테이블과 수수료율 테이블과 최근가 테이블과 수정 이력 테이블을 같이 고쳐야 하는지가 문제였다.

Open Table of contents

전송이 읽는 컬럼

밖으로 나갈 때 어느 컬럼을 읽는지를 전송 코드에서 확인했다. 원본 테이블의 두 컬럼만 읽어 페이로드를 만들고 있었다.

다섯 테이블을 각각 검색했더니 페이로드 구성 코드에서는 하나도 안 읽었다. 용도를 확인하니 마지막 전송 값 기록과 정산 계산과 이력과 감사로 전부 정산과 감사 용도였다.

이것으로 결론이 났는데 판매가만 바꿀 때는 연관 테이블에 추가 조치가 필요 없다는 것이었다. 다섯 테이블을 같이 갱신하려던 계획이 없어졌다.

전송 페이로드가 어느 컬럼을 읽는지를 코드에서 확인하는 것만으로 작업 범위가 다섯 테이블에서 두 컬럼으로 줄었다.

연동 테이블에 가격 일치 여부를 담는 불리언 컬럼이 있어서 그것이 전송을 막는지가 걸렸다. 이름만 보면 조건문에 쓰일 것처럼 생긴 컬럼이었다.

쓰는 곳을 검색하니 두 곳이었고 하나는 외부에서 가격을 수집할 때 현재가와 비교해 기록하는 자리이고 다른 하나는 가격 불일치 리포트의 필터였다. 기록하고 리포트에서 걸러 보여 줄 뿐 전송을 건너뛰거나 분기하지 않았다.

이것을 게이트로 봤으면 가격을 바꾸면 그 플래그가 거짓이 되어 전송이 막힐 것으로 판단해 플래그도 같이 갱신했을 것이다. 안 해도 되는 조작이 하나 늘어난다.

그리고 그 갱신이 리포트를 왜곡하는데 실제로는 불일치인데 일치로 표시된다. 이름이 용도를 말해 주지 않으므로 쓰는 곳을 검색해 확인해야 하고 결과 수가 적으면 그 확인이 금방 끝난다.

코드로 확인한 뒤 실제로 원본 컬럼만 바꾸고 전송을 걸어 봤다. 연관 테이블을 안 건드렸는데 네 채널에 정상으로 전송됐다.

이 조합이 필요한 이유는 코드를 읽어도 다른 경로가 있을 수 있고 실측은 실제로 어느 경로를 탔는지를 확인해 주기 때문이다. 둘이 같은 결론을 내면 그때 확정된다.