Bom dia, Feliz ano novo.
Estou estudando o hibernate e cheguei na herança.Vi que sao possiveis 3 tipos :.SINGLE_TABLE,TABLE_PER_CLASS,JOINED.
Como estou iniciando no hibernate, gostaria de saber qual delas é a melhor usar, ou o uso especifico de cada uma vai depender do que eu quero, ou se posso adotar uma como regra sempre que precisar usar herança, enfim.
Tem uma melhor e mais indicada?
Agradeço e espero respostas pois acho que muitas pessoas têm essa duvida.
Muito Obrigado
Estratégia de Herança!Qual a melhor?
3 Respostas
Nesse blog tem dois posts que explicam duas dessas estratégias: Uma tabela por herança, JPA Uma Classe por Sub-Classe.
Falta ainda escrever sobre a terceira. :oops:
Basicamente, uma salva toda a herança em uma tabela e deixa apenas um campo como identificador, outra salva apenas os devidos campos de cada classe em cada tabela, e a ultima salva todos os atributos em todas as tabelas por classe.
Explicar resumido fica meio difícil. [=
é basicamente como o jakefrog disse, vou explicar um pouco mais detalhado (e dar exemplos básicos para uso, obviamente simplificando os modelos de dados e regras de negócio)
Para a SINGLE_TABLE, podemos usar como exemplo funcionário -> [funcionário horista, funcionário mensalista] (o exemplo padrão para esse caso, rsrs)
O funcionário horista e o funcionário mensalista tem as mesmas propriedades, diferenciando os métodos que buscam, por exemplo
[list]
FUNCIONARIO
nome
setor
valor
tipo_funcionario
salário
[/list]
Na classe, teríamos uma funcionário, uma funcionário horista, e uma funcionário mensalista (ou semanalista, etc…). Repare que na modelagem de dados, ter tudo numa única tabela é melhor, pois podemos fazer consultas, agrupamentos, etc… direto nos dados armazenados, em todos os funcionários de uma só vez. Bem como no modelo de negócios, temos bem organizado funcionários horistas, mensalistas, semanalistas, etc… Todos organizados de forma a obtermos de forma prática e rápida as consultas que viríamos fazer, por exemplo, buscar os funcionários de um setor, os setores com maior custo no final do mês, maiores salários no fim do mês, etc…
No TABLE_PER_CLASS, se fosse usar a regra de negócios do exemplo anterior, teria uma tabela para horista, outra para semanalista, outra para mensalista, etc… Para essa regra de negócios (dos funcionários ) não seria muito interessante utilizar a TABLE_PER_CLASS. Mas vamos para um exemplo da TABLE_PER_CLASS.
Tenho que persistir chamadas telefônicas, as chamadas telefonicas “locais”, tem:
[list]
telefone_origem
telefone_destino
dia_inicio
hora_inicio
dia_fim
hora_fim
localidade_origem (código nacional de localidades)
localidade_destino
[/list]
As chamadas telefonicas longa distância
[list]
telefone_origem
telefone_destino
dia_inicio
hora_inicio
dia_fim
hora_fim
ddd_origem
ddd_destino
[/list]
repare que as propriedades de cada chamada são diferentes, portanto, não posso colocar tudo em uma única tabela, e que chamadas telefônicas dependendo da empresa vai desprender um volume de dados muito grande, vou ter melhor desempenho na base de dados tendo essa regra em tabelas separadas e não preciso fazer joins para obter objetos.
Já o JOINED, se eu tivesse que fazer no caso anterior, um join para obter cada chamada, quanto não sobrecarregaria a base de dados? É justificado ter , para o exemplo anterior, uma tabela com telefone_origem, telefone_destino, dia/hora inicio, dia/hora fim? (propriedades comuns) Pode até ser dependendo da regra de negócios a ser aplicada, mas dá para ver que na maioria das regras de negócios aplicadas a esse caso não teria melhor organização e desempenho né?
Como exemplo do JOINED, vamos dizer que eu tenho uma classe Pessoa, que é pai de Pessoa Física e Pessoa Jurídica. Pessoa Física tem CPF, RG, etc… Pessoa Jurídica tem CNPJ, entre outros. Mas, para relacionarmos clientes por exemplo, vou ter que ter um ID de Pessoa né? Posso ter Clientes tanto Pessoa Física quanto Pessoa Jurídica, se eu tivesse uma tabela por classe, onde eu teria o ID da pessoa para relacionar na tabela de clientes? Tendo uma tabela de pessoa com nome, endereço, etc… já tenho o que preciso para identificar clientes, para, por exemplo, fazer uma lista de clientes, só vou limitar o que é pessoa física ou pessoa jurídica em algum caso específico.
Bom, foram exemplos simples para entender que não existe “um melhor que o outro”, se existisse não teria porque aprendermos os 3, heheheh.
evefuji foi simplesmente ótima sua resposta.
Realmente vi que tudo vai depender das regras de negócio para definir a estratégia de herança.
Já estou estudando as três e estou fazendo testes e exemplos.
Muito obrigado pela sua ajuda.
Feliz Ano novo pra você e pra todos do GUJ.
Obrigado