Exemplos De Nomes Proprios

Como escolher e validar nomes próprios em sistemas

Muita gente acha que lidar com nomes próprios é simples porque basta deixar o campo livre. Na prática, isso gera uma série de problemas que aparecem só quando o sistema vai para produção. Eu já vi banco de dados inteiros sendo comprometidos por nomes mal tratados, então vou explicar como fazer isso direito. Nomes próprios em português precisam lidar com questões que outras línguas não têm, como acentos, hífens e partículas de preposição. Veja alguns casos reais que eu encontrei em bancos de dados durante minha carreira. Maria da Graça Santos — aqui a partícula "da" precisa ser preservada e não removida por filtros automatizados. Já vi sistemas que cortavam esse tipo de partícula e misturavam o nome corretamente.

José Carlos da Silva-Ferreira — nomes compostos com hífen aparecem frequentemente em Portugal e no Brasil. O travessão não deve ser convertido nem removido. Alguns validadores de formulário trocam hífens por espaços ou espaços por hífens, criando registros duplicados e inválidos. André-Louis Nguyen — combinação de partícula francesa com sobrenome vietnamita. Isso é mais comum do que se imagina, especialmente em cidades como São Paulo e Lisboa. O systema precisa aceitar caracteres Unicode sem alterar a sequência original. Roberto João III — sufixos honoríficos também são parte do nome próprio. Não se deve separar o "III" do restante como se fosse um campo diferente.

O problema que todo mundo encontra pela primeira vez é o seguinte: você cadastra um usuário com o nome completo e depois tenta fazer uma busca por ele. O sistema usa LIKE com comparação case-sensitive, ou pior, transforma tudo para minúsculas e remove acentos antes de buscar. O resultado é que "Maria da Graça" não encontra "maria da graça" mesmo quando dever-se-ia encontrar. A solução técnica simples é usarCOLLATE adequado no banco de dados. No PostgreSQL, o collate pt_BR funciona bem. No MySQL, a configuração padrão já lida razoavelmente com isso, mas é preciso verificar. Outro caso que eu enfrentei foi com o registro de clientes em um ERP brasileiro. Tinha um fornecedor chamado "Sá", com cedilha e acento agudo no final. O sistema armazenava como "Sa" e apagava o acento automaticamente. Quando esse mesmo fornecedor entrava em contratos com outros parceiros que mantinham o nome correto, gerava uma divergência de CPF que ninguém conseguia resolver sem intervenção manual. A correção foi desabilitar a normalização automática de acentos nos campos de nome e implementar uma validação que compara o nome digitado diretamente contra o registro do governo, mantendo a grafia original.

O que funciona e onde falha

Existem algumas regras que eu uso rotineiramente e que reduzem bastante o trabalho de manutenção posterior. Primeiro, nunca normalizes nomes para comparar. Salva exatamente como o usuário digitou. Se precisar de busca, implementa fuzzy matching ou normaliza apenas na camada de query, nunca na camada de armazenamento. Segundo, separar nome e sobrenome é tentador mas raro funciona bem. Nomes como "Mary Jane Watson" ou "Luiz Inácio Lula da Silva" não se encaixam em dois campos. O ideal é ter um campo único para nome completo e, se necessário, campos derivados para ordenação ou busca. Nunca force a divisão em nome/sobrenome num formulário.

Terceiro, valide contra a realidade do usuário. Se o campo permite até 200 caracteres, aceite até 200 caracteres. Eu já vi sistemas que cortavam nomes com 250 caracteres automaticamente, gerando cadastros inválidos para pessoas cujos nomes são naturalmente longos. Nomes de povos originários e de famílias com muitas gerações registradas no nome são exemplos frequentes. O ponto onde isso mais falha é em integrações com sistemas legados. Bancos de dados antigos que usam VARCHAR(50) ou VARCHAR(100) vão quebrar nomes maiores. Não tem isso além de ajustar o schema. Se você não pode mudar o banco, a alternativa é truncar com aviso ao usuário e pedir confirmação explícita. É melhor o usuário reclamar do que perder dados permanentemente. Para quem está começando, o conselho é simples: teste com dados reais desde o início. Nomes fictícios como "João da Silva" ou "Maria Oliveira" passam em todos os testes e não revelam nenhum dos problemas descritos aqui. Use nomes reais de pessoas que você conhece, ou pegue exemplos de sites de tribunais públicos e listas de eleitores. Esses documentos contêm a diversidade completa de nomes que seu sistema vai encontrar.

O tempo que isso leva para configurar corretamente varia. Se você está partindo do zero, entre 4 e 6 horas para implementar validação, collation adequada e testes. Se está migrando um sistema existente, espere dobrar esse tempo para limpar os dados já cadastrados incorretamente. O processo de limpeza costuma ser o mais demorado, porque envolve identificar duplicidades causadas por normalizações inconsistentes e consolidar registros que pertencem à mesma pessoa. Se o seu sistema precisa apenas de um campo simples para cadastro e não vai fazer cruzamento com bases governamentais, talvez não precise de todo esse cuidado. Mas se há qualquer integração ou relatório que envolva identificação pessoal, o esforço vale a pena. Dados errados sobre nomes próprios causam transtornos reais para as pessoas e retrabalho constante para a equipe de suporte. Não subestime a complexidade.