국제 주소 데이터베이스 설계: 필드, 원시 값, 버전 관리

별도의 입력, 구문 분석된 구성 요소 및 렌더링된 출력

원시 입력은 증거이고 구문 분석된 필드는 검색 및 비즈니스 논리를 지원하며 렌더링된 라인은 국가 순서를 따릅니다. 하나만 유지하면 나중에 감사하고 파서를 업그레이드할 수 없습니다.

rawAddressLines, parsedComponents, normalizedAddress 및 정규화 공급자/버전을 저장합니다. 정규화 실패로 인해 원시 레코드가 삭제되어서는 안 됩니다.

숫자로 보이는 식별자는 여전히 텍스트입니다.

우편번호와 집 번호에는 앞에 0, 문자, 공백, 하이픈 및 범위가 포함될 수 있습니다. 정수 유형은 데이터를 손실하고 국가별 패치를 적용합니다.

전체적으로 Unicode 텍스트를 사용하세요. 평균적인 영어 샘플이 아닌 실제 데이터세트와 비즈니스 경계에서 길이 제한을 도출합니다.

type PostalAddress = {
  countryCode: string;
  addressLines: string[];
  adminArea1?: string;
  adminArea2?: string;
  adminArea3?: string;
  locality?: string;
  postalCode?: string;
  rawAddress: unknown;
};

빈 문자열, null 및 누락을 혼합하지 마십시오.

없는 두 번째 줄이 생략되거나, null이거나, 비어 있는지 정의한 다음 경계에서 정규화합니다. 그렇지 않은 경우 쿼리, 중복 제거 및 내보내기는 하나의 상태를 3으로 처리합니다.

누락된 줄을 N/A 또는 대시로 채우지 마십시오. 자리 표시자가 라벨에 누출됩니다.

주문 및 감사 기록에 스냅샷 사용

주소록 항목은 변경될 수 있지만 주문이나 송장은 과거 주소를 유지해야 합니다. 현재 addressId만 참조하면 기록이 변경됩니다.

스냅샷 렌더링된 라인, 구성 요소, 확인 상태 및 타임스탬프.

• 주문은 주소록에 따라 변경되지 않습니다.
• 노멀라이저 공급자 및 버전 기록
• 타임스탬프 확인 상태
• 불필요하게 전체 실제 주소를 기록하지 마세요.

여러 국가의 테스트 픽스처로 마이그레이션 검증

영국식 건물명, 캐나다 영숫자 우편번호, 독일어 Unicode, 일본어 소스 텍스트 및 앞에 0이 포함된 왕복 여행 일정입니다. 행 개수만 비교하는 것이 아니라 의미 체계 필드와 원시 JSON를 비교하세요.

마이그레이션 리허설에서는 잘린 값, 디코딩 실패 및 빈 문자열에서 Null로의 변경을 계산해야 합니다. 응용 프로그램이 원본 줄을 다시 읽은 후 다시 구성할 수 없으면 데이터베이스 성공만으로는 충분하지 않습니다. 이전 레코드와 새 레코드 간의 구조적 차이를 생성하고 되돌릴 수 없는 변환을 위해 보유된 rawAddress 데이터의 재생 경로를 준비합니다.

깨끗한 테스트 데이터베이스와 프로덕션 기반 스키마의 정리된 복사본 모두에 대해 이 제품군을 실행하세요. 현실적인 인덱스, 제약 조건 및 레거시 Null은 이상적인 빈 스키마가 재현할 수 없는 동작을 드러내는 경우가 많습니다.

애플리케이션 읽기 경로와 마이그레이션 작업을 측정합니다. ORM 직렬 변환기, 검색 색인, 캐시 또는 분석 내보내기는 데이터베이스가 새 열 모양을 승인한 후에도 여전히 이전 열 모양을 가정할 수 있습니다. 모든 대표 기록에 대해 고객이 보는 것, 이행이 수신되는 것, 감사 내보내기를 통해 보존되는 것 등을 비교하십시오. 해당 소비자가 동일한 주소 버전에 동의하는 경우에만 릴리스하고 이전 열이나 원시 페이로드가 제거되기 전에 롤백 결정 지점을 유지하십시오. 마이그레이션 릴리스 기록과 함께 최종 비교를 문서화하십시오.

• Unicode 문자열과 JSON 구조 비교
• 카운트 잘림, 인코딩 및 Null 변환
• 애플리케이션 계층을 통해 읽기
• 원시 주소 재생 도구 유지