Relacionamento Opcional no hibernate (chaves estrangeiras permitindo valores null)
3 respostas
rodrigo.bossini
Pessoal,
Consideremos o seguinte exemplo:
Um Cliente pode ter de 1 a N automóveis.
Um automóvel pode ter 0 ou 1 dono.
Trata-se de um relacionamento 1 x N, onde automóvel “puxa” a chave de cliente.
idCliente em Automóvel é uma chave estrangeira. Neste caso, dado o fato de o relacionamento ser opcional, é totalmente aceitável que esta chave estrangeira aceite valores nulos.
Minha pergunta é:
Como é que o Hibernate implementa isso na prática?
Ele de fato cria uma coluna FK que aceita null, ou cria uma outra tabela somente para armzenar os relacionamentos?
Hibernate cria? vc usar o hibernate pra criar suas tabelas?
Na prática ele vai deixar o objeto como null e vai tentar inserir null na coluna do banco.
J
jcmaster
Desculpe invadir esse tópico, mas, Felagund, não é uma boa idéia deixar o Hibernate criar as tabelas? O correto seria criar as tabelas e mapear depois no hibernate? Pergunto pq, quase sempre, optei pela primeira opção, já que, quase sempre tenho o diagrama de classes, então gero as classes e o hibernate gera as tabelas pra mim. Isso não é aconselhavel?
Obrigado.
Felagund
jcmaster:
Desculpe invadir esse tópico, mas, Felagund, não é uma boa idéia deixar o Hibernate criar as tabelas? O correto seria criar as tabelas e mapear depois no hibernate? Pergunto pq, quase sempre, optei pela primeira opção, já que, quase sempre tenho o diagrama de classes, então gero as classes e o hibernate gera as tabelas pra mim. Isso não é aconselhavel?
Obrigado.
Não que eu veja problema no Hibernate criar as tabelas, mas eu prefiro criar as tabelas manuais, para garantir que os NOT NULL, DEFAULT etc, que podem ser esquecidos qdo vc mapeia a entidade, dai vem um FDP (sempre tem um), que insere os valores errados na tabela e vc tem alguns NullPointer para tratar, pq de acordo com sua aplicação o campo nunca vai ser null, então vc nem se encomoda em tratar alguns desses casos.
