식별자를 쓰기 전에 두 가지를 확인한다

필드를 식별자로 쓰기 전:

1. 유일한가 — 값이 겹치지 않는가
2. 식별용인가 — 그 필드가 대상을 지목하려고 존재하는가

①만 보고 ②를 안 보면 태그 같은 검색용 필드를 키로 쓴다.

②만 보고 ①을 안 보면 정식 식별자에 절단·부모공유로 당한다.

쓴 필드	깨진 조건
외부 SKU 필드	① — 20자에서 절단 저장. 중복이 전체의 40%대
상품 이름으로 인덱싱	①② — 상태 파일이 섞여 본문 없는 껍데기가 선점
상품명 매칭	② — 3연속 사고
플랫폼 tags	② — 검색용 롱테일. 태그 하나로 품목 오분류
진행 파일명	① — 다른 스크립트가 다른 형식으로 같은 이름 사용 → 200여 건 유실
카테고리 이름	② — 부분일치 오탐. 리프 ID로 고정해 해결
한 레코드의 두 필드	① — 키와 URL이 서로 다른 대상을 가리킴
메일 발신 도메인	② — 대행 발송 인프라의 도메인이라 모든 스토어가 같은 값. 표시이름(From display name)으로 2차 판별

규율

• 교차 검증 없이 단일 필드로 매칭하지 않는다
• 매칭 결과는 표본을 눈으로 검수한다. 수십 건짜리 오매칭 계획이 "이름이 그럴듯해서" 통과할 뻔했다
• 새 진행 파일은 선점 확인 후 만든다: grep -rn "파일명" *.py
• 한 레코드 안에 같은 대상을 가리키는 필드가 둘이면 반드시 대조한다. 어긋나도 아무 에러가 안 난다

절단 키로 접두 조회할 때는 유일할 때만 채택한다

외부 SKU가 20자에서 잘리니 원본 키로는 못 찾고 접두로 찾게 된다. 한 브랜드 300건 중 42건이 앞 20자가 충돌했다. 후보가 2건 이상이면 매칭을 포기하고 유사도 폴백으로 넘긴다. 오연결보다 미연결이 낫다.

연결률은 고정 분모(등록분) 대비로 잰다. 맵 총계는 다른 스크립트가 계속 추가해 분모가 자라므로, 총계 대비로 보면 진척이 없어 보인다.

확장자·선언 MIME은 포맷의 증거가 아니다

PNG 바이트를 image/jpeg로 선언해 올렸더니 업로드 400. 파일명과 선언은 사람이 붙인 라벨이고 ②를 만족하지 않는다. 매직 바이트로 포맷을 판정하고, 상대가 받는 포맷으로 변환한 뒤 올린다.

한 레코드의 두 필드가 어긋났을 때의 교정 절차

1,928건 중 46건에서 키와 URL이 서로 다른 상품을 가리켰다. 발주 시 다른 물건을 사게 되는 직접 사고 경로다.

1. 별도 색인에 등록된 쪽을 정본으로 삼는다 — 키가 SKU 색인에 있으면 키를 믿는다
2. 반대쪽(URL)을 정본에서 재생성한다
3. 등재 시점에 두 필드가 같은 대상인지 검증을 건다. 사후 대조보다 싸다

"다른 것이 같은 이름"의 반대 — 같은 것이 다른 이름을 얻었다

.job_seen과 .jobs_seen이 따로 있었다. 복수형 s 하나로 처리 이력이 두 파일에 쪼개졌다. A가 기록한 걸 B가 몰라 다시 처리하고, B가 기록한 걸 A가 몰라 안 보냈다. 에러는 없다. 오타가 아니라 별개 파일로 성립해버린다.

• 상태 파일 경로는 상수 한 곳에 정의한다. 문자열 리터럴로 흩지 않는다
• 비슷한 이름이 둘 이상 보이면 그 자체가 신호다 — 단·복수, 언더스코어 유무, 축약형

표의 진행 파일명 행과 정확히 대칭이다. 저건 다른 것이 같은 이름, 이건 같은 것이 다른 이름. 둘 다 이름을 계약으로 안 잡아서 생긴다.

---

---