Propriedades específicas em modelagem de dados: o que funciona e o que quebra no dia a dia
Propriedades específicas são atributos únicos de uma entidade que não podem ser mapeados para um tipo genérico ou herdado. Elas existem porque o mundo real raramente se encaixa em hierarquias limpas. Você cria um modelo abstrato e, na primeira vez que precisa salvar dados reais, percebe que algo não casa. Aí entram as propriedades específicas.
Como definir propriedades específicas na prática
O processo começa identificando atributos que só fazem sentido em determinados subtipos. Vou dar um exemplo direto. Imagine que você está construindo um sistema de gestão de veículos. A classe base tem marca, modelo e ano. Mas um caminhão precisa ter capacidade de carga, enquanto um carro de corrida precisa ter potência em cv e categoria de homologação. Esses campos são propriedades específicas. A abordagem mais comum é usar herança de tabela. Você cria uma tabela pai com os campos compartilhados e tabelas filhos para cada subtipo com suas propriedades específicas. Funciona. A maioria dos desenvolvedores inicia assim. O problema é que essa estratégia tende a escalar mal quando o número de subclasses cresce acima de cinco ou seis. Você termina com uma dezena de tabelas quase vazias e joins que matam a performance.
Outra alternativa é usar JSON fields. O PostgreSQL suporta isso nativamente com o tipo jsonb e permite indexação via GIN. Você guarda as propriedades específicas dentro de uma coluna JSON dentro da tabela principal. Consulta rápida, schema flexível. A desvantagem é que você perde integridade referencial automática e validação em nível de banco. Precisa cuidar disso na aplicação. A terceira opção, menos óbvia mas que resolve muitos casos, é o padrão EAV (Entity-Attribute-Value). Cada propriedade específica vira uma linha em uma tabela separada com chave estrangeira para a entidade. É útil quando as propriedades variam muito entre categorias e você não sabe de antemão quais serão necessárias. A consulta fica mais complicada porque você precisa pivotar colunas na mão, mas evita a fragmentação de tabelas.
Um caso real que me custou duas semanas
Há uns três anos eu trabalhava em um sistema de cadastro de equipamentos industriais. A equipe decidiu usar herança de tabela. Tínhamos equipamentos elétricos, hidráulicos, pneumáticos e uma mistura híbrida que aparecia com frequência. O problema era que um equipamento pneumático poderia ter propriedades específicas de pressão e fluxo, mas também poderia ter sensores elétricos acoplados. A modelagem em tabelas separadas criava ambiguidade: onde colocar essas propriedades híbridas? A solução que encontrei foi migrar para jsonb no PostgreSQL. Criamos uma coluna "especificacoes" do tipo jsonb na tabela principal de equipamentos. Para cada tipo de equipamento, definimos um schema de validação usando jsonschema na camada de serviço. Assim, as propriedades específicas eram validadas antes de chegar ao banco. A migração levou cerca de três dias, mas eliminou pelo menos meia dúzia de workarounds que tínhamos criado anteriormente.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O custo foi ter que reescrever todas as consultas que antes usavam JOINs simples. Consultas que antes levavam 40ms passaram a depender de operações de extracão de campo JSON, mas com indexação adequada via expression index, o tempo caiu para cerca de 60ms em média. Aceitável para a flexibilidade que ganhamos.
Dicas que ninguém conta sobre propriedades específicas
A primeira coisa que todo mundo erra é tentar prever todas as propriedades específicas desde o início. Você vai falhar nisso. Comece com as óbvias e deixe o resto para evoluir. O segundo erro comum é misturar propriedades específicas com metadados operacionais na mesma estrutura. Separe isso claramente. Propriedades específicas descrevem o que o objeto é. Metadados descrevem como o sistema lida com ele. São camadas diferentes. Uma armadilha menos discutida envolve serialização. Quando você expõe propriedades específicas via API, o consumidor muitas vezes não sabe quais campos esperar. A solução padrão é devolver um esquema discoverável junto com os dados, mas isso adiciona overhead. Em sistemas com alto tráfego, costumo limitar o número de propriedades específicas retornadas por consulta e oferecer um endpoint separado para metadados do esquema.
Performance também merece atenção. Indexar colunas jsonb exige expression indices com funções como jsonb_path_query. Uma consulta mal indexada pode transformar um operation de milissegundos em algo que demora segundos. Sempre verifique o plano de execução antes de confiar na velocidade. Se o seu cenário tem propriedades específicas extremamente numerosas e mutáveis, considere alternativas como grafos.Neo4j lida bem com esse padrão sem a rigidez de schemas relacionais. Não é a resposta para tudo, mas em certos contextos elimina problemas que tabelas JSON e EAV ainda deixam residuais.
Para quem quer implementar jsonb com validação no PostgreSQL, o pacote jsonschema do Python ou a biblioteca Joi do Node são bons pontos de partida. O código de validação fica relativamente enxuto e evita que dados inconsistentes entrem no banco.
