Olá pessoal!
Tenho uma dúvida que é totalmente conceitual, principalmente, do ponto de vista das boas práticas.
Estou desenvolvendo um sistema para apuração de custos através de documentos(Contratos, requisição de materiais, folha de pagamento etc).
Analisando esses documentos notei que existem um grupo de informações idênticas entre eles e que não são grandes as informações que variam, sendo assim, optei por criar uma tabela “Documento” que contem todos os atributos de todos os documentos que serão tratados no sistema. Até ai, beleza! A dúvida é como tratar isso na aplicação:
Estou utilizando vRaptor3 com Hibernate, então pensei em criar uma superclasse “Documento” com os atributos que são comuns a todos os documentos e criar subclasses para cada tipo de documento(Contratos, requisição de materiais, folha de pagamento etc) herdando os atributos da classe documento, porém, não tenho certeza se essa é a melhor forma de tratar a questão.
Fiz uma pesquisa na net e achei um artigo do Paulo Silveira http://blog.caelum.com.br/jpa-com-hibernate-heranca-e-mapeamentos/ que diz: Muitos administradores de banco de dados reclamam dessa estratégia, sendo que a mais elegante é a InheritanceType.JOINED, onde cada classe terá uma tabela, mas sem repetir colunas. As tabelas que representam as classes filhas possuem uma chave estrangeira para a tabela que representa a mãe, normalizando o banco nesse aspecto.
Não sei se entendi direito e nem se os meus conhecimentos de modelagem e normalização de dados estão atualizados, mas olhando para o banco de dados, não achei que ter uma tabela “Documento” com meia dúzia de atributos e uma outra tabela “DocumentoContrato” com o restante dos atributos fosse necessário e muito menos funcional/performático.
No fundo, eu quero é a opinião dos colegas sobre a forma mais adequada, tanto do ponto de vista da “elegância” como da performance e também das futuras manutenções nessa aplicação e, caso eu tenha entendido errado o texto do artigo, se alguém pode me indicar alguma material pra eu me aprofundar nesse assunto.
Desde já agradeço os que puderem opinar.
Mauricio
Camarada, em modelagem relacional, (DER), você possui uma coisa chamada generalização/especialização, que é quase igual ao conceito de herança. A tabela ‘pai’ tem as suas colunas e as tabelas filhas possuem as delas, sempre com uma FK que referencia a PK da tabela ‘pai’.
Isso vai além, a referência à PK da tabela ‘pai’ vai a todas as tabelas filhas, as filhas das filhas, as filhas das filhas das filhas e assim por diante (sabe aquela coisa dos árabes colocarem nos seus filhos ‘bin’? Então, mais ou menos isso).
A estratégia JOINED atende ao que a generalização/especialização prega.
A estratégia JOINED deixa seu banco de dados modelado, usando uma FK para as tabelas “filhas” da PK “pai”.
Você ganha em modelagem, mais perde em questão de busca, pq sempre terá que fazer join para trazer as consultas.
[quote=JUniorDOzito]A estratégia JOINED deixa seu banco de dados modelado, usando uma FK para as tabelas “filhas” da PK “pai”.
Você ganha em modelagem, mais perde em questão de busca, pq sempre terá que fazer join para trazer as consultas.[/quote]
Join não significa perda de desempenho, a não ser que não saiba o que se está fazendo.
Significa uma melhor organização das coisas.
[quote=drsmachado][quote=JUniorDOzito]A estratégia JOINED deixa seu banco de dados modelado, usando uma FK para as tabelas “filhas” da PK “pai”.
Você ganha em modelagem, mais perde em questão de busca, pq sempre terá que fazer join para trazer as consultas.[/quote]
Join não significa perda de desempenho, a não ser que não saiba o que se está fazendo.
Significa uma melhor organização das coisas.[/quote]
Não disse que perde desempenho, mais é diferente da estrategia SINGLE_TABLE que não faz join, pq fica tudo junto em uma unica tabela e a modelagem de dados vai pro espaço!
Se perde desempenho ou não, a questão é que usando a estrategia JOINED terá que fazer join para fazer buscas nas tabelas!..
Ahan, o que quis dizer com ‘mais perde em questão de busca’ padawan?
Eu não ficar aqui me explicando!
O que aprendi e li sobre o assunto é isso que disse!
O consumo de espaço utilizando a estratégia Joined é menor do que o utilizado pela estratégia
Single Table. Contudo, as consultas são mais lentas, pois é necessário realizar operações de join para
recuperar os dados dos objetos.
Agora vai me dizer que os livros e tutoriais que li são mentirosos ou vc é que sabe mais…
PADAWAN?..que birosca é isso?..
[quote=JUniorDOzito]Eu não ficar aqui me explicando!
O que aprendi e li sobre o assunto é isso que disse!
O consumo de espaço utilizando a estratégia Joined é menor do que o utilizado pela estratégia
Single Table. Contudo, as consultas são mais lentas, pois é necessário realizar operações de join para
recuperar os dados dos objetos.
Agora vai me dizer que os livros e tutoriais que li são mentirosos ou vc é que sabe mais…
PADAWAN?..que birosca é isso?..[/quote]
Não assistiu Star Wars pelo visto…
Então vai o Mestre Jedi, tira a dúvida do mrcbrizoti…