Como lidar com nomes de cidades que contêm a letra N em bases de dados
Quem já precisou fazer filtros ou validações em listas de cidades brasileiras sabe que a letra N aparece com frequência e gera confusão na hora de processar os dados. A maioria das pessoas subestima o problema porque acha que basta um `LIKE '%n%'` e pronto. Não é bem assim. No dia a dia, especialmente quando se trabalha com APIs de IBGE, planilhas de clientes ou bancos legado, a variação entre maiúsculas e minúsculas, acentos e espaços extras transforma uma operação simples em dor de cabeça. Eu já perdi horas rastreando por que uma cidade como "Niterói" não era reconhecida em um sistema de endereçamento enquanto "Natal" funcionava perfeitamente. O motivo era inconsistência na higienização dos dados antes da consulta.
O que considerar ao buscar nome de cidade com a letra n
O primeiro passo é normalizar a string antes de qualquer comparação. Converter tudo para lowercase, remover acentos e trim nos espaços. Um script rápido de pré-processamento resolve 80% dos problemas que vejo em rodadas de revisão de código. Aqui vai um exemplo prático de como eu trato isso:
Normalizo com `unicodedata.normalize('NFD', texto).encode('ASCII', 'ignore').decode()` no Python, ou equivalente em SQL com funções de substituição. Depois aplico o filtro `WHERE LOWER(cidade) LIKE '%n%'`. Parece óbvio, mas a maioria dos scripts que encontro por aí pula essa etapa. Tive um caso recente em que precisei cruzar uma base de 40 mil registros de cidades com outra tabela de usuários. A query original levava 12 minutos porque fazia match direto sem normalização, comparando "Niterói" com "niterói" e falhando nos acentos. Após adicionar a normalização e um índice Function-Based na coluna cidade, o tempo caiu para 47 segundos. A diferença é brutal e não tem segredo.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O problema é que nem sempre o ambiente permite índices customizados. Em sistemas legados rodando em SQL Server ou MySQL com configurações padrão de collation, o `LIKE '%n%'` pode ignorer acentos de formas imprevisíveis dependendo da configuração do banco. Nesse cenário, a normalização via aplicação é a única saída confiável. Outro ponto que poucos mencionam: cidades com nomes que começam com N ou que têm N no início de sílabas são mais suscetíveis a erros de digitação manual. "Nova Friburgo" vira "Nova Friburgo", "Nova Iguaçu" vira "Nova Igassu", e o filtro quebra. Se o seu sistema recebe entrada humana, considere oferecer autocompletar com validação contra a tabela oficial do IBGE antes de salvar.
Se você está trabalhando com muitos nomes de cidades e precisa de uma referência confiável, a base oficial do IBGE está disponível gratuitamente no site deles, atualizada anualmente. Baixe o arquivo TXT ou CSV e faça o update periódico na sua tabela de cidades. Evita muita dor de cabeça com municípios que foram criados ou tiveram nome alterado.
Pegadinhas comuns
Dobre-check a collation do seu banco antes de escrever a query. Uma collation case-insensitive já resolve metade dos problemas sem código extra. Se estiver usando PostgreSQL, verifique se a extensão `unaccent` está instalada — ela remove acentos de forma eficiente e evita a necessidade de lógica customizada. Em MySQL, a collation `utf8mb4_general_ci` é case-insensitive mas tem comportamento estranho com certos caracteres especiais. Prefira `utf8mb4_unicode_ci` se a performance não for crítica. A diferença de velocidade é marginal na maioria dos casos e a correção dos acentos vale o custo.
Por fim, se o volume de dados for grande demais para processamento via aplicação, considere materializar uma coluna normalizada na própria tabela. Atualize via trigger ou job agendado. Gasta espaço em disco, mas elimina a sobrecarga de processamento a cada consulta e estabiliza a performance a longo prazo.
