A correspondência de nomes de países e aliases é o problema que aparece depois que a base já existe, quando alguém tenta agrupar registros e descobre que o mesmo lugar está escrito de quatro maneiras. A tentação é resolver com comparação aproximada, e ela funciona até o momento em que dois lugares diferentes são tratados como um só. Este texto mostra como montar esse mecanismo na ordem certa.
Por que um mesmo país tem várias formas de nome?
Porque nome de país é um objeto linguístico e administrativo, não um identificador. Ele muda conforme quem escreve, em qual idioma, em qual época e com qual nível de formalidade.
Na prática, convivem pelo menos cinco famílias de forma. O nome formal completo, usado em documentos oficiais. O nome curto, usado no dia a dia e na interface. O nome no idioma local, que pode usar outro alfabeto ou outros sinais. O nome histórico, que aparece em bases antigas e em documentos arquivados. E as formas abreviadas ou coloquiais, usadas internamente por equipes de operação.
A essas famílias somam-se variações de transliteração. Quando um nome passa de um alfabeto para outro, existem sistemas diferentes de representação, e eles produzem resultados que um humano reconhece como o mesmo lugar e uma comparação literal não reconhece.
Definir o nome canônico antes de qualquer comparação
A primeira decisão não é técnica, é editorial: escolha qual forma é o nome canônico de exibição e registre essa escolha. Sem essa definição, cada tela resolve a questão por conta própria e a inconsistência se espalha.
O nome canônico precisa de três propriedades. Ele deve ser único dentro do catálogo, não deve depender do idioma da interface se for usado em relatórios, e deve ser estável no tempo, mudando apenas por decisão registrada.
Uma segunda decisão acompanha a primeira: qual é a chave. A recomendação, repetida em vários pontos do site, é que a chave não seja o nome. Nomes mudam; chaves precisam durar. O nome canônico é uma escolha de exibição, e a chave é a identidade.
Quando essas duas coisas ficam separadas, a mudança de nome de um lugar passa a ser uma edição de rótulo. Quando ficam juntas, a mesma mudança vira migração de dados, e migrações feitas sob pressão são onde os registros se perdem.
A ordem correta entre normalização e comparação
A ordem importa mais do que o algoritmo escolhido. A regra é normalizar para comparar e preservar para exibir.
Isso significa que a forma originalmente digitada ou recebida é guardada como veio, e uma versão normalizada é derivada para fins de busca e de correspondência. Se a normalização for aplicada à gravação, a informação original desaparece, e a equipe perde a capacidade de investigar por que duas entradas não se encontraram.
Sobre o que a normalização deve fazer, existem operações seguras e operações arriscadas. Seguras: padronizar espaços, remover diferenças de caixa, aplicar uma forma de composição uniforme de caracteres acentuados. Arriscadas: remover sinais diacríticos, que em alguns idiomas mudam a letra e não apenas a aparência, e converter alfabetos, que exige um sistema declarado e reversível.
O erro clássico é comparar antes de normalizar. Duas formas que parecem idênticas na tela podem não ser idênticas na memória, e o resultado é um sistema em que o usuário vê dois itens iguais e não entende por que precisa escolher entre eles.
| Operação | Efeito | Risco |
|---|---|---|
| Padronizar espaços e caixa | Aproxima formas evidentes | Baixo |
| Uniformizar composição de acentos | Elimina diferença invisível | Baixo |
| Remover sinais diacríticos | Aumenta acertos na busca | Pode fundir nomes distintos |
| Transliterar alfabeto | Permite busca em outro alfabeto | Exige sistema declarado |
Quando a comparação aproximada atrapalha?
Atrapalha quando é usada como chave em vez de como sugestão. Um mecanismo aproximado tem como objetivo produzir candidatos, e não decidir sozinho; quando ele decide, dois lugares distintos podem ser fundidos em um único registro.
A fusão é praticamente irreversível. Depois que dois lugares viram um, separar exige reconstruir qual parte de cada dado pertencia a quem, tarefa que costuma ser mais cara do que o problema original. Por isso a recomendação é sempre a mesma: em caso de dúvida, apresente a lista de candidatos e deixe a decisão para quem conhece o domínio.
Existe um segundo abuso frequente: usar comparação aproximada para bloquear entrada. Rejeitar um valor porque ele se parece com uma forma conhecida, mas não é exatamente ela, transforma uma variação legítima em erro de usuário.
Um caso particular merece cuidado: nomes que são prefixo de outros. Comparações por início de texto tendem a tratar um nome curto como correspondência de vários nomes longos, e o resultado é uma lista de sugestões que não ajuda ninguém.
Nome de exibição e chave de armazenamento
Manter os dois separados resolve uma família inteira de problemas. A chave identifica o registro e nunca muda. O nome de exibição pode variar por idioma, por contexto editorial e por decisão de produto.
Com essa separação, três operações ficam simples. A primeira é traduzir a interface sem tocar nos dados. A segunda é corrigir a grafia de um nome sem migrar registros. A terceira é comparar bases diferentes pela chave, mesmo que cada uma exiba um nome distinto.
Vale também definir o que acontece quando um nome antigo deixa de ser usado. A chave continua válida, e o nome antigo passa a integrar a tabela de aliases, com a data a partir da qual ele deixou de ser o principal. Assim, uma busca por um termo antigo continua encontrando o registro correto.
Um exemplo de território com nome reconhecido de mais de uma forma aparece na página do Brasil no catálogo, onde a mesma entrada é descrita por diferentes colunas e precisa continuar coerente entre elas. E a parte de estrutura interna, que também tem nomenclatura própria, é tratada em dados de nome por localidade.
Para quem desenvolve: uma tabela de aliases auditável
A recomendação prática é ter uma tabela explícita de aliases, e não regras implícitas espalhadas pelo código. Cada linha associa uma forma alternativa à chave, e cada linha tem uma origem: quem a cadastrou, quando e com base em que.
Três verificações mantêm a tabela saudável. A primeira é de unicidade: uma mesma forma alternativa não deve apontar para duas chaves diferentes, porque isso é ambiguidade que o sistema não tem como resolver sozinho. A segunda é de cobertura: formas antigas devem continuar presentes depois da mudança de nome. A terceira é de revisão: a tabela precisa de um responsável, do contrário acumula entradas erradas que ninguém corrige.
Ao comparar, prefira a igualdade após normalização como caminho principal e a aproximação como último recurso, sempre com confirmação. Nesse desenho, o custo de uma correspondência errada cai a quase zero, porque a decisão final é humana.
Próximos passos
Se o ponto de entrada desses nomes é o campo de seleção e a busca, veja teste de campo de seleção de país. Se a origem das formas divergentes é a combinação entre idioma e região, o texto país e idioma são coisas diferentes explica como separar os eixos. E a página de formatos de endereço e identidade por país permite conferir a nomenclatura usada no catálogo antes de fechar a sua própria.
Ressalva: as tabelas de aliases e as variações de grafia usadas neste texto foram inventadas para ilustrar o método de correspondência. Elas não reproduzem nenhuma lista oficial de nomes e não devem ser usadas para validar nomenclatura em um sistema real.