Design de banco de dados de endereços internacionais: campos, valores brutos e versionamento

Entrada separada, componentes analisados e saída renderizada

A entrada bruta é uma evidência, os campos analisados suportam a lógica de pesquisa e de negócios e as linhas renderizadas seguem a ordem do país. Manter apenas um evita auditorias posteriores e atualizações do analisador.

Armazene rawAddressLines, parsedComponents, normalizedAddress e provedor/versão de normalização. Uma falha de normalização não deve destruir o registro bruto.

Identificadores que parecem numéricos ainda são texto

Os códigos postais e os números das casas podem conter zeros à esquerda, letras, espaços, hifens e intervalos. Os tipos inteiros perdem dados e forçam patches específicos do país.

Use o texto Unicode por toda parte. Obtenha limites de comprimento a partir de conjuntos de dados reais e limites de negócios, e não de amostras médias em inglês.

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

Não misture strings vazias, nulas e ausentes

Defina se uma segunda linha ausente é omitida, nula ou vazia e normalize no limite. Caso contrário, a consulta, a desduplicação e as exportações tratam um estado como três.

Nunca preencha as linhas faltantes com N/A ou travessão; os espaços reservados vazam nas etiquetas.

Use instantâneos para pedidos e registros de auditoria

Uma entrada do catálogo de endereços pode mudar, enquanto um pedido ou fatura deve preservar seu endereço histórico. Fazer referência apenas a um addressId atual altera o histórico.

Linhas renderizadas de instantâneo, componentes, status de verificação e carimbo de data/hora.

• Os pedidos não mudam com o catálogo de endereços
• Provedor e versão do normalizador de registros
• Status de verificação do carimbo de data/hora
• Não registre endereços reais completos desnecessariamente

Verifique migrações com fixtures de vários países

Equipamentos de ida e volta contendo instalações nomeadas no Reino Unido, código postal alfanumérico canadense, alemão Unicode, texto fonte em japonês e zeros à esquerda. Compare campos semânticos e JSON brutos, não apenas contagens de linhas.

Um ensaio de migração deve contar valores truncados, falhas de decodificação e alterações de string vazia para nula. O sucesso do banco de dados não é suficiente se o aplicativo não conseguir reconstruir as linhas originais após lê-las. Produza uma diferença estrutural entre registros antigos e novos e prepare um caminho de reprodução a partir de dados rawAddress retidos para transformações irreversíveis.

Execute esse conjunto em um banco de dados de teste limpo e em uma cópia higienizada de esquemas em formato de produção. Índices realistas, restrições e nulos herdados geralmente revelam comportamentos que um esquema vazio ideal não pode reproduzir.

Meça o caminho de leitura do aplicativo, bem como o trabalho de migração. Um serializador ORM, índice de pesquisa, cache ou exportação de análise ainda pode assumir o formato de coluna anterior depois que o banco de dados aceitar o novo. Para cada registro representativo, compare o que o cliente vê, o que a operação de fulfillment recebe e o que uma exportação de auditoria preserva. Libere somente quando esses consumidores concordarem com a mesma versão de endereço e mantenha um ponto de decisão de reversão antes que colunas antigas ou cargas brutas sejam removidas. Documente a comparação final juntamente com o registro da versão de migração.

• Compare strings Unicode e estrutura JSON
• Contar truncamento, codificação e conversões nulas
• Leia a camada de aplicação
• Mantenha uma ferramenta de repetição de endereço bruto