Como implementar categoria masculina e feminina em sistemas de cadastro
O problema que todo mundo encontra na prática é bem simples: você precisa criar um campo de classificação de gênero em algum sistema, banco de dados ou formulário, e logo de cara percebe que não é tão trivial quanto colocar "masculino" e "feminino" e pronto. Já perdi tempo configurando validações que quebravam quando o usuário escolhia outra opção, e também vi formulários que rejeitavam campos vazios em contextos onde o gênero não era realmente obrigatório. A parte mais importante não é escolher entre usar ENUM no banco de dados ou uma tabela separada. É decidir desde o início se esse campo será obrigatório ou opcional, porque isso define toda a estrutura ao redor dele. No meu caso, Working em um sistema de RH há alguns anos, me deparei com um bug chato: o sistema legado usava códigos numéricos (1 para masculino, 2 para feminino) e quando tentamos integrar com um módulo novo que esperava strings, simplesmente travou. A solução foi criar uma view de mapeamento que fazia a conversão transparente, sem quebrar nada.
categoria masculina e feminina na prática
Existem basicamente três abordagens que funcionam no mundo real. A primeira é a tabela de dados completa. Você cria uma tabela dedicada com colunas para id, codigo, descricao, ativo e talvez ordem. Insere os valores possíveis, habilita e desabilita conforme necessidade. A vantagem é que você consegue adicionar novas categorias depois sem tocar na estrutura do banco. O drawback é que para um campo binário simples isso é overkill, e a consulta fica um pouco mais verbosa com joins. A segunda abordagem é usar valores fixos mesmo dentro do banco, seja como ENUM ou CHECK constraint. Fica mais rápido porque não tem join, mas qualquer mudança futura exige migração de schema. Em ambientes que passam por auditorias rigorosas, prefiro evitar ENUM porque ele é implementado de forma diferente em cada SGBD e isso gera dor de cabeça quando você migra de um banco para outro.
A terceira é o campo nullable com validação na camada de aplicação. Funciona bem quando o gênero não é informação crítica para o sistema, mas exige que toda aplicação que consuma esse dado saiba tratar valores nulos corretamente. Se qualquer uma das telas ou APIs esquece disso, você terá registros inconsistentes espalhados pelo sistema. O que as pessoas geralmente erram é tratar isso como um problema puramente técnico. Na verdade, a decisão mais importante é sobre como o sistema vai lidar com pessoas que não se encaixam nas categorias binárias. Já vi sistemas inteiros quebrarem porque alguém decidiu que o campo deveria ser obrigatório e fechado, e aí surgiram registros problemáticos que ninguém sabia como corrigir. A solução mais razoável hoje em dia é fazer o campo opcional e, se precisar de obrigatoriedade por algum motivo regulamentar, permitir ao menos uma categoria "outro" ou "prefiro não informar" que não gere erro de validação.
Outro detalhe que causa dor de cabeça é a padronização dos dados já existentes. Quando você começa a implementar isso em um sistema que já está rodando há anos, a maioria dos registros antigos provavelmente não tem esse campo preenchido, ou tem valores inconsistentes — abreviações, maiúsculas e minúsculas misturadas, erros de digitação. Antes de qualquer coisa, rode um SELECT de análise para ver o estado atual. Isso vai te dar uma ideia realista de quanto trabalho de limpeza você vai ter pela frente. Para quem está começando do zero e quer algo prático, aqui vai um exemplo mínimo de como eu configuro isso atualmente. A tabela de categorias:
👉 Clique no botão abaixo para saber mais sobre o assunto!
CREATE TABLE categoria_genero (id SERIAL PRIMARY KEY, codigo VARCHAR(20) UNIQUE NOT NULL, descricao VARCHAR(50) NOT NULL, ativo BOOLEAN DEFAULT TRUE, ordem INTEGER); E os inserts iniciais:
INSERT INTO categoria_genero (codigo, descricao, ordem) VALUES ('M', 'Masculino', 1), ('F', 'Feminino', 2), ('O', 'Outro', 3), ('N', 'Prefiro não informar', 4); O campo na tabela principal fica como integer referencing a tabela de categorias, e é nullable. Na camada de aplicação, a validação checa apenas se o valor referenciado existe na tabela e está ativo, sem de nenhuma forma.
Se o seu sistema é pequeno e não prevê crescimento, você pode simplificar usando varchar direto na tabela principal com uma constraint check. Mas tenha em mente que se no futuro você precisar adicionar uma quinta categoria ou mudar alguma descrição, vai ter que fazer atualização em lote nos dados existentes além da mudança no schema. Esse tipo de situação me custou uma madrugada inteira de trabalho em algum momento, então recomendo não subestimar. A parte de frontend também merece atenção. Um select simples funcionando é o mínimo, mas o ideal é que as opções sejam carregadas dinamicamente da API ou do banco, nunca fixas no código da tela. Já vi equipes inteiro manterem listas duplicadas no frontend e no backend, o que gera inconsistência rapidamente assim que alguém atualiza um lado e esquece o outro.
Se você precisa de algo mais robusto e estruturado, frameworks como Django e Rails já trazem patterns consolidados para esse tipo de classificação. Mesmo que não use um deles, dá para copiar a lógica: tabela de lookup, field foreign key, validação em cascade. Não tem porque reinventar isso manualmente a cada projeto novo. O ponto final que vale repetir é que categoria masculina e feminina parece simples até você precisar dar manutenção em um sistema que está no ar há anos e percebe que a decisão que tomou no início limitou cada mudança que veio depois. Começar com flexibilidade desde o dia um evita dor de cabeça considerável.
