Cidade Com A Letra Z

Como lidar com cidades que contêm a letra Z em sistemas de dados

Muita gente subestima a simples operação de filtrar cidades pela letra Z em bases de dados geográficas. Parece bobo no início, mas logo você descobre que existem armadilhas reais quando o assunto é normalização, acentuação e duplicação de registros.

O problema prático com cidade com a letra z

Vou ser direto: o maior erro que vejo todo dia é tratar o Z maiúsculo e minúsculo como coisas diferentes quando na verdade não são. Mas tem outro detalhe que pega muita gente. Cidades como "Carazinho" no Rio Grande do Sul ou "Franca" que não tem Z mesmo, mas às vezes entra por erro de digitação. Já perdi duas horas limpando base porque um sistema antigo gravava "Zezinho" no lugar de "Joãozinho" como nome de cidade fictícia em dados de teste. O filtro básico com LIKE '%Z%' ou LOWER(nome) LIKE '%z%' parece simples, mas cai em ciladas frequentes. Nomes como "São Gabriel da Cachoeira" não têm Z, ok, mas cidades como "Juazeiro do Norte" têm o Z no meio. E aí você começa a perceber que o problema não é só encontrar, é encontrar certo.

A abordagem que funciona na prática

Aqui vai o método que eu uso e que tem funcionado consistentemente. Primeiro, normaliza tudo. Remove acentos, converte para minúsculas, remove caracteres especiais que às vezes aparecem em cadastros antigos. O banco de dados IBGE tem a tabela de municípios atualizada, mas se você está lidando com dados próprios, o processo é diferente. Segundo passo: faça a filtragem em três camadas. A primeira filtra por presença de Z maiúsculo. A segunda por Z minúsculo. A terceira por variantes como 'z' que apareceram em OCR de documentos digitalizados. Juntar tudo com DISTINCT resolve a maioria dos casos.

Um exemplo concreto. Eu estava processando uma base de aproximadamente 5 mil registros de cidades brasileiras e encontrei onze variações do mesmo município só por causa de Z. "Presidente Prudente" não tem Z, mas "Muzambinho" tem e aparecia em três formas diferentes no mesmo arquivo. O workaround foi criar uma coluna de hash normalizado e usar ela como chave primária temporária durante o tratamento.

Armadilhas que ninguém alerta

A primeira armadilha é achar que a base do IBGE é perfeita. Ela é muito boa, mas quando você junta com dados de outros bancos, como registros de receita federal ou cadastros estaduais, aparecem cidades com nomes ligeiramente diferentes. "Nova Friburgo" vs "Nova Fribugro" não é diferença de Z, mas é o tipo de coisa que quebra filtros Ingênuos. A segunda armadilha é mais sutil e acontece quando você exporta os resultados. Alguns sistemas convertem Z para algo estranho em codificação errada. Se você está usando arquivos CSV com encoding errado, o Z pode virar um caractere estranho e seu filtro simplesmente some com metade dos resultados. Use sempre UTF-8 sem BOM.

Quando o método falha completamente

Se sua base tiver mais de 500 mil registros de cidades com dados provenientes de múltiplas fontes não correlacionadas, esse enfoque manual de normalização perde eficiência. Nesses casos, o custo benefício inverte e vale mais a pena usar um engine de correspondência fuzzy como Dedupe ou até mesmo uma consulta com edit distance configurada. Eu já vi gente gastando dias com scripts caseiros quando uma query com Levenshtein resolve em minutos. Também não adianta muito processar cidades brasileiras se o seu foco for cidades de outros países lusófonos. "Luanda" não tem Z, mas cidades em Moçambique ou Angola podem ter grafias muito divergentes das variantes brasileiras, e o mesmo filtro simplesmente não generaliza.

O que funciona para cidade com a letra z em bases brasileiras é basicamente normalização agressiva seguida de deduplicação por hash, mas cada base tem suas particularidades. Teste sempre com uma amostra antes de rodar em produção.