Definir uma pessoa parece simples até você tentar fazer isso em qualquer sistema real
Todo mundo acha que saber o nome de alguém é suficiente. Não é. Eu já perdi tempo demais tentando conciliar cadastros duplicados porque duas pessoas tinham o mesmo nome e sobrenome, nasceram no mesmo município, e o sistema não tinha como diferenciá-las. A questão nunca é só coletar dados. É decidir quais dados importam, quando eles se tornam confiáveis e o que você faz quando as informações conflitam. Em termos técnicos, definir uma pessoa envolve pelo menos quatro camadas que quase ninguém considera antes de começar: a identificação única, os atributos vinculados, a fonte de verdade e as regras de atualização. Se você pular alguma delas, o modelo vai quebrar na primeira vez que precisar cruzar dados entre sistemas diferentes.
Como definir uma pessoa de forma prática
O caminho mais direto começa com um identificador único. CPF no Brasil, social security number nos Estados Unidos, ou algum GUID que você gera internamente se estiver montando um sistema do zero. Identificador único não é sinônimo de chave primária de banco de dados, embora muitas vezes seja a mesma coisa. São conceitos diferentes. A chave primária garante integridade dentro do seu sistema. O identificador único deve fazer sentido fora dele também, para que outras aplicações consigam referenciar essa pessoa sem adivinhar. Depois vem os atributos. Nome completo, data de nascimento, documentos oficiais, endereço, contatos. Aqui tem uma armadilha comum que eu vi gente cair várias vezes: tratar nome como campo único. Nome é composto, tem variações, tem gente que casou e mudou sobrenome, temgente que tem nome social, tem gente que simplesmente não quer que todos os sobrenomes apareçam em todos os lugares. Separe primeiro nome, sobrenome, e campos adicionais como nome social ou apelido registrado. Trate cada um como opcional, não como obrigatório.
A fonte de verdade é o ponto onde a maioria dos projetos tropeça. De onde vêm os dados? Do próprio usuário preenchendo um formulário? De integração com outro sistema? De algum governo ou base pública? Cada fonte tem um nível diferente de confiabilidade. Formulário autodeclarado é informação, não fato confirmado. Integração com backend administrativo costuma ser mais confiável, mas ainda pode estar desatualizada. Eu trabalhei num projeto onde a fonte de verdade era o cadastro do governo, mas o prazo de sincronia era de trinta dias. Entre uma atualização e outra, o sistema carregava dados que já estavam errados por meses. A solução foi marcar explicitamente cada campo com sua fonte e um timestamp de última verificação, e tratar dados sem fonte confirmada como rascunho, não como definitivo. Por fim, as regras de atualização. Quem pode mudar o quê, quando e com quê provas. Mudança de nome exige documentação? Alteração de data de nascimento precisa de comprovação? Endereço novo só precisa de CEP ou tem que bater com algo externo? Sem essas regras definidas antes, você vai ter pessoas com três endereços simultâneos, dois CPFs vinculados ao mesmo registro, e histórico de alterações que não faz sentido nenhum.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Eu já enfrentei um caso específico em que um usuário atualizava o próprio endereço todos os meses porque o sistema não pedia comprovação. A primeira vez que notei, pareceu coincidência. Na décima segunda alteração, o padrão ficou claro demais. Bloqueei mudanças repetidas do mesmo campo sem reforço de verificação e solicitei confirmação por outro canal. O problema reduziu pela metade na primeira semana. O que poucos levam em conta é que definir uma pessoa não é um evento. É um processo contínuo. Dados mudam. Pessoas morrem, se mudam, mudam de nome, são incorporadas a sistemas diferentes que usam convenções incompatíveis. O modelo que você montar hoje vai precisar sobreviver a isso sem se desfazer.
Se o seu objetivo é puramente técnico, considere usar um padrão como o Schema.org Person, ou o modelo da ISO/IEC 29003-1 para troca de dados de identificação. Eles não resolvem todos os problemas, mas dão um ponto de partida que evita reinventar estrutura toda vez que você precisar representar alguém. Importante: "como definir uma pessoa" é uma pergunta que responde melhor quando você especifica o contexto. Definir uma pessoa num cadastro médico é diferente de definir no financeiro, que é diferente de definir num sistema escolar. Os campos, as regras e as fontes de verdade mudam conforme o domínio. Tentar criar um modelo universal costuma produzir um modelo que não serve bem para nenhum deles.
Só mais um detalhe prático. Evite normalizar nomes em caixa alta sem dar ao usuário a opção de preservar a grafia original. Eu vi sistema que transformava "Maria Clara" em "MARIA CLARA" e apagava todas as variantes. Quando a pessoa precisou provar o nome exato do documento, o sistema não conseguia mais encontrar o registro correspondente. Armazene a versão canônica para buscas, mas preserve a grafia original para apresentação. Não existe definição perfeita. Existe definição que funciona para o caso que você está resolvendo agora e que não vai te pegar de surpresa quando o problema aparecer. A melhor abordagem é começar pequeno, documentar as decisões que você toma sobre cada campo, e revisar regularmente quando novos cenários aparecerem.
