Descrever pessoas em bancos de dados e sistemas
Eu trabalho com modelagem de dados há mais de uma década, e já vi gente gastar dias inteiros tentando definir o que "descrição de pessoas" significa numa tabela SQL ou dentro de um CRM antes mesmo de saber quais campos realmente importam. O problema não é a falta de opção — é exatamente o contrário. O primeiro passo que todo mundo acerta errado é começar pela lista de campos possíveis em vez de pelo fluxo real de uso. Quando comecei num projeto interno de gestão de clientes, minha equipe tentou mapear cerca de sessenta atributos por pessoa. Acabamos descartando cinquenta e dois porque ninguém preenchia esses campos. Restaram oito que efetivamente alimentavam as consultas e relatórios que os gerentes usavam todo dia. A descrição de pessoas só faz sentido quando você sabe quem vai ler, quem vai atualizar, e sob qual formato aqueles dados vão parar num dashboard ou numa integração de API.
Por onde começar na descrição de pessoas
O jeito mais barato de validar se a estrutura está boa é montar um CSV com linhas de exemplo e mandá-lo para três pessoas que vão usar o sistema no dia a dia. Se duas delas não souberem o que preencher num campo novo, esse campo tá errado ou mal nomeado. Eu costumava chamar isso de teste do "olho cansado": alguém que passa duas horas por semana lidando com aquelas informações deve conseguir identificar em dois segundos o que cada coluna representa. Na prática, eu divido os campos em três camadas. A primeira é a identidade básica — nome completo, data de nascimento, documento de identificação principal, e um campo único que nunca se repete, como CPF ou outro identificador oficial do país. A segunda camada reúne contatos e canais, mas apenas os que realmente precisam ser consultados: e-mail, telefone residencial e telefone comercial. O resto é ruído. A terceira camada é a parte que mais gera erro, que inclui relacionamentos e contextos — departamento, cargo, status de matrícula, origem do cadastro. Esses campos dependem do tipo de sistema, e é aí que muita gente erra ao copiar modelos prontos da internet sem ajustar para o contexto local.
Um detalhe que poucas pessoas mencionam é a diferença entre descrição de pessoas como entidade estática e como histórico. Um cadastro comum guarda o estado atual. Mas quando você precisa rastrear mudanças — alguém mudou de e-mail, saiu do emprego, voltou, o endereço foi atualizado — a abordagem correta não é sobrescrever a linha existente, e sim registrar a movimentação numa tabela separada com data de início e data de fim. Isso parece óbvio, mas eu já vi projetos inteiros perderem semanas porque as equipes resolveram adicionar colunas com sufixos como _v1, _v2, _v3, o que quebra qualquer consulta e transforma o banco num documento sem estrutura.
Armazenamento e privacidade
Se o seu sistema opera no Brasil ou atende cidadãos brasileiros, a descrição de pessoas inevitavelmente toca a LGPD. Dados como CPF, biometria, localização habitual e até o e-mail pessoal quando vinculado a uma pessoa física específica são tratados como dados pessoais sensíveis em certos contextos. O simples fato de descrever uma pessoa num banco de dados já cria obrigação de registre a base legal do tratamento — consentimento, execução contratual, legítimo interesse — porque sem esse registro qualquer auditoria encontrará um campo vazio e marcará o item como não conformidade. Uma pegadinha prática que eu encontrei diversas vezes é a necessidade de anonimização em tabelas de log. Você pode manter o histórico completo para fins operacionais, mas o log de acesso, os relatórios de auditoria e os ambientes de desenvolvimento devem operar com dados mascarados ou sintéticos. Máscara básica funciona para CPF — manter só os três últimos dígitos e substituir o resto por asteriscos. Para nomes, um pseudônimo estático gera um mapping consistente em todos os ambientes, o que permite testar consultas reais sem expor identidade.
O custo de implementar isso logo no início é menor do que corrigir depois. Em projetos que eu acompanhei, a migração de uma tabela de pessoas para um esquema compatível com retenção limitada e pseudonimização levou, na média, entre quatro e oito horas de trabalho para dados que já estavam estruturados corretamente. Se a descrição de pessoas nunca foi pensada com privacidade, a mesma migração pode levar semanas, porque o time acaba precisando reconstruir relacionamentos, refazer integrações e revalidar permissões de acesso.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Campos que eu sempre incluo e campos que eu sempre removo
Os campos padrão que aparecem em quase todo modelo que eu reviso e que eu recomendo manter são: identificador único, nome completo, data de nascimento, sexo ou gênero quando relevante para o contexto operacional, documento oficial principal, e-mail, telefone residencial, telefone comercial, endereço completo dividido em logical fields como CEP, logradouro, número, complemento, bairro, cidade e estado. Quando o sistema é corporativo, eu adiciono identificador interno, data de admissão, cargo atual, manager_id, e status. Quando é acadêmico, eu substituo por matrícula, curso, período de ingresso e situação cadastral. Os campos que eu sempre removo por serem inúteis na maioria dos casos são: aparência física, cor dos olhos, altura, peso, número de calçado, estado civil completo com detalhes sobre cônjuges anteriores, religião, orientação política, e histórico deendereço completo com todos os lugares que a pessoa morou nos últimos vinte anos. A última linha parece inofensiva, mas eu já vi empresas guardarem isso por padrão, o que gera retrabalho excessivo e aumenta o risco de vazamento sem nenhuma contrapartida operacional. Se o negócio precisa saber onde a pessoa mora hoje para entrega ou visita, um único endereço atual basta.
Existe ainda um erro recorrente de quem desenha a descrição de pessoas sem pensar em nomes compostos. Nomes como Maria da Conceição Silva dos Santos não se encaixam bem em campos fixos como first_name e last_name. Eu recomendo usar um único campo name completo, com um campo normalized_name para indexação, e deixar a análise em first/last/middle para ferramentas de processamento de linguagem natural se virarem. Tentar dividir manualmente gera erros de ortografia, exclusões indevidas e perda de referências históricas que depois aparecem em contratos e documentos legais.
Validação e qualidade dos dados
Validação não é sinônimo de obrigatoriedade. Campo obrigatório é uma decisão de negócio; validação é garantir que o valor inserido respeita um formato conhecido. Na prática, eu implemento três camadas. A primeira é regex simples para e-mail e telefone. A segunda é consulta a APIs externas quando faz sentido — consultas de CEP via Correios ou ViaCEP no Brasil, validação de CPF por algoritmo de dígitos verificadores. A terceira é regra de domínio, como impedir que uma pessoa seja cadastrada com data de nascimento posterior à data de hoje, ou que o CPF informado já exista em outra linha ativa. Um problema real que eu encontrei recentemente envolveu duplicação de descrição de pessoas causada por diferentes transliterações de nomes estrangeiros. Um sistema recebeu cadastros de um colaborador estrangeiro registrados de três formas distintas: Yuki Tanaka, Yuki Tanakah, e Tanaka Yuki. As regras de deduplicação padrão não funcionaram porque a similaridade de string era baixa. A solução que funcionou foi combinar três sinais: CPF/id único quando disponível, nome normalizado, e data de nascimento. Quando os três coincidiam, o sistema unificava automaticamente e gerava um relatório de auditoria. Quando faltava algum sinal, o registro ficava em estado pendente para revisão humana. Esse padrão reduziu nossa taxa de duplicação de 14% para menos de 0,8% em três meses.
Outro ponto que eu considero crítico na descrição de pessoas é a rastreabilidade de quem criou e quem alterou. Campo created_by, created_at, updated_by, updated_at são baratos de adicionar no início e caríssimos de implementar depois. Eu costumo colocar triggers no banco para preenchê-los automaticamente, evitando que aplicativos se esqueçam de registrar essas informações durante insert ou update.
Modelo mínimo recomendável
Se você precisa de um ponto de partida prático, o modelo que eu recomendo começa com uma tabela persons contendo person_id, uuid, full_name, normalized_name, birth_date, gender, cpf, email, phone_home, phone_work, address_id, status, created_at, created_by, updated_at, updated_by. Uma tabela separada para addresses com address_id, cep, logradouro, numero, complemento, bairro, cidade, estado, pais, validade. E uma tabela history_person_address ou person_events caso precise rastrear movimentações. Isso cobre cerca de 90% dos casos comuns sem criar complexidade desnecessária. Se seu cenário exige mais detalhes — como histórico profissional, vínculos familiares, ou atributos específicos de saúde no contexto de RH — você expande com tabelas relacionadas em vez de adicionar colunas na tabela principal. Tabelas normalizadas facilitam queries, mantêm a descrição de pessoas enxuta e deixam a expansão futura mais barata. Cada coluna nova na tabela de pessoas custa mais do que parece: aumenta o tempo de backup, amplia a superfície de exposição em vazamentos, força atualizações de índices e, em bancos que usam partitioning, pode mudar a estratégia de partição inteira.
Resumindo sem fazer resumo: comece pelo uso, não pela lista de campos. Valide com quem vai operar. Mantenha privacidade desde o dia um. E nunca esqueça de rastrear quem alterou o quê e quando. O resto é ajuste fino conforme o sistema cresce.
