Estou com uma dúvida com relação ao mapeamento de chaves compostas.
A situação é a seguinte:
Tenho uma classe cuja a Chave primaria da mesma é composta por duas outras classes, porém tenho uma terceira classe que chave desta terceira é uma composta da outra classe que a chave ja é composta.
A dúvida seria, utilizando embeddable eu irei referenciar a classe em si ou a sua chave?.
Exemplificando para facilitar o entendimento;
classe 1 (chave composta)
Apolice --> chave (ApolicePK embeddable)
classe 2 (chave composta)
Arquivo —> chave (é embeddable porém não sei se referencio Apolice ou ApolicePK)
Primeiro, eu acho isso uma aberração da modelagem SQL. Chaves compostas precisam ser usadas com parcimônia. Mas, cada um sabe como faz…
Segundo, você está se referindo a uma pesquisa na tabela arquivo, através de chave, certo? Neste caso, a raiz da pesquisa deve ser o objeto de ApolicePK, afinal, é este que e´a chave da chave Apolice (eu não consigo acostumar com isso, criar um novo atributo e nomeá-lo como PK seria tão mais bonito).
Entrando no contexto de Modelagem lógica deste projeto a forma correta seria a utilização de uma chave composta sim por regra normal e não por “estética”.
Talvez o seu argumento de criar um atributo e o definir como chave primaria seria útil para outro “mini-mundo”, porém neste mesmo não seria valido.
Estamos falando de modelagem baseada em um DER/MER? Se for isso, então esqueça o uso de um framework ORM, afinal, você está direcionando o desenvolvimento para o modelo lógico do banco de dados, logo, deve seguir toda a estrutura arquitetônica com base nisso.
Por outro lado, se você pretende usar algo de mais alto nível, como o Hibernate, então eu sugiro que você faça um mapeamento partindo dos teus objetos. Assim sendo, você (não só pode, como) deve simplificar ao máximo.
A ideia de chaves compostas em cascata (seguindo as boas práticas de modelagem de tabelas, você deve colocar as referências a todas as tabelas que estão acima da última tabela dependente, ou seja, se tem 10 tabelas dependentes, a 11ª terá 10 chaves estrangeiras se referindo à toda árvore que vem acima dela) é necessária e faz sentido apenas em modelos estruturados. Quando o assunto é modelagem orientada a objetos, isso não tem necessidade, pois eu não tenho uma chave referindo ao objeto que determinada instância possui, eu tenho os objetos dentro desta instância.
Exatamente. Use Hibernate se sua modelagem for OO. Se for relacional, não perca tempo com Hibernate, quem faz isso é só fpra forçar a barra pra usar a ferramenta.
Um dos erros mais comuns de quem começa a aprender determinada ferramenta, framework, linguagem, metodologia, etc é a sensação de que isso é a única coisa que salva o mundo.
Só que não é.
Afinal, para quê aprender outros design patterns, se o façade resolve tudo?
Que microservices o que, minha arquitetura monolítica é muitas vezes superior.
Há razões para se usar uma abordagem, ferramenta, framework. E muito mais razões para não se usar.
Se o banco de dados é modelado conforme você está colocando, criar as queries na mão é muito mais simples, fácil e produtivo.
Você pensa em termos de tabelas, colunas e, só então, se preocupa com como este ou aquele objeto ficará.
Por outro lado, se você não tem um banco de dados que atenda às 5 formas normais e etc, analise e verifique se é o caso de utilizar hibernate mesmo. Pode ser complicado e difícil de manter depois.