키가 아니라 인코딩된 값

문의에 상품 주문 번호라고 적힌 값이 둘 있어서 그대로 조회했더니 아무것도 안 나왔다. 다른 테이블에서도 찾아봤지만 전부 0건이었다.

Open Table of contents

조회로는 안 나오던 번호

번호 형식은 정상으로 보였고 자릿수도 그럴듯했다. 그런데 어느 테이블에서도 그 값을 키로 가진 행이 없었다.

설정 파일을 열어 보니 식별자 공간마다 다른 파라미터 세트가 정의돼 있었다. 밖으로 나가는 번호는 내부 키가 아니라 그 파라미터로 인코딩한 값이었다.

문제는 어느 세트로 풀어야 하는지가 번호만 봐서는 안 나온다는 점이었다. 세트마다 결과가 전혀 다른 값으로 나온다.

그래서 후보 세트를 전부 풀어 보고 실재하는 행이 나오는 쪽을 채택했다. 값 자체로는 못 고르므로 존재 여부가 유일한 기준이었다.

이 인코딩의 성질이 판별을 어렵게 만들었다. 보통의 변환은 틀린 키로 풀면 깨진 값이 나와서 틀렸다는 것이 바로 보인다.

여기서는 틀린 세트로 풀어도 그럴듯한 정수가 나오므로 틀린 것이 틀려 보이지 않는다. 조회해서 없다는 것을 확인하기 전까지는 맞는 값으로 보인다.

풀어서 나온 두 값을 조회하니 둘 다 있었는데 서로 다른 주문이고 다른 채널이었다. 교환 재배송 문의라 원본과 교환 건으로 짐작하고 있었다.

그 가정 때문에 초반 조사가 엉켰고 한쪽 채널의 흐름으로 해석하다 다른 쪽 데이터가 안 맞아 데이터가 이상하다고 봤다. 이상했던 것은 데이터가 아니라 두 번호가 같은 대상일 것이라는 가정이었다.

절차를 정하면서 파라미터를 메모에 적어 두고 쓰지 않기로 했다. 설정이 바뀌면 메모가 틀리고 틀린 값으로 풀어도 유효해 보이는 다른 수가 나온다.

그래서 설정 파일에서 그때그때 읽는다고 적었다. 문의에 적힌 번호는 각각 독립적으로 대상을 확정한 뒤에 관계를 확인한다는 것도 함께 남겼다.