[RESOLVIDO] String como chave primária no Hibernate, é possível?

Assuntos Gerais
#1

Opa pessoal, tudo bem?

Criei uma entidade País para ser inserida no banco de dados via Hibernate:

//imports do javax.persistence...

@Entity
public class Pais {
    @Id    
    private String sgPais; //Exemplo: BRA
    private String dsPais; //BRASIL
    private int cdDDI;     //55

    //Construtores, getters e setters.
}

Mas na hora de salvar ( session.save(meuPais) ) não salva, ele cria a tabela certinha, mas fica em branco. A session está configurada certinha, pois tenho outra classe que usa um int como ID e salva. Nessa outra classe, a diferença é que uso um @GeneratedValue no int também, seria isso? O problema é que @GeneratedValue para String dá erro.

Estou usando o banco de dados MySQL.

Obrigado de qualquer forma.

#2

Vou te dar uma sugestão.

Para todas as suas classes, sempre mantenha o id como um long ou int. O id vai ser apenas uma chave artificial (surrogate). Ai para a sigla e para os outros campos que não podem ser duplicados indique que é unique.

Ai você pode ficar pensando… Mas e o meu DER e o MR? Meu MR diz que a minha chave primária é a sigla! Não posso usar esse id…
Bem, para os mais puristas, você não pode mesmo, mas usando o surrogate você ganha performance. Imagine a sigla como chave estrangeira em outra tabela. 3 caracteres. Enquanto o surrogate gastaria um número. Imagine então um CPF como FK! 14 caracteres com os pontos e o traço. Enquanto o surrogate usaria apenas um número.

Entendeu o esquema?

[]´s

#3

[quote=davidbuzatto]Vou te dar uma sugestão.

Para todas as suas classes, sempre mantenha o id como um long ou int. O id vai ser apenas uma chave artificial (surrogate). Ai para a sigla e para os outros campos que não podem ser duplicados indique que é unique.

Ai você pode ficar pensando… Mas e o meu DER e o MR? Meu MR diz que a minha chave primária é a sigla! Não posso usar esse id…
Bem, para os mais puristas, você não pode mesmo, mas usando o surrogate você ganha performance. Imagine a sigla como chave estrangeira em outra tabela. 3 caracteres. Enquanto o surrogate gastaria um número. Imagine então um CPF como FK! 14 caracteres com os pontos e o traço. Enquanto o surrogate usaria apenas um número.

Entendeu o esquema?

[]´s[/quote]
Oi David,

Entendi sim, eu colocaria algo como 1 - BRA - Brasil - 55, sendo o 1 a verdadeira chave para o banco. Realmente ficaria bem melhor a performance, além de resolver meu problema! :slight_smile:
Para eu indicar que é unique, é só uma anotação @Unique no campo ? (Estou sem meu computador mesmo para testar)

Obrigado
[]

#4

Olá,

Depois da anotação Entity a antes da definição da classe, coloque a seguinte anotação:

[]´s

#5

[quote=davidbuzatto]Olá,

Depois da anotação Entity a antes da definição da classe, coloque a seguinte anotação:

[]´s[/quote]

Muito obrigado David, funcionou direitinho.

Você conhece algum bom site de exemplos e tutoriais para tirar essas dúvidas de Hibernate?

#6

Olá,

Gosto do livro Java Persistence with Hibernate.

[]´s

#7

Pessoal, eu estou num dilema.
estou trabalhando em uma aplicação multi cliente e cada cliente tem seus respectivos dados.

Pensando em uma funcionalidade que me foi solicitada, backup dos dados, que no caso, devem ser feitos somente dos dados de um determinado cliente, não podendo por exemplo ter informações de outro cliente, pelo simples princípio de sigilio de informação.

No caso, acredito que se usar chave surrogate (id tipo Long), as relações entre minhas entidades, no caso de um backup e um possível restore ou mesmo a migração para um banco de dados diferente, se perderiam! Chave surrogates não são confiáveis neste meu ponto de vista, sempre trabalhei com elas, mas neste caso não posso.

Bom, vi a discussão inicial e recomendam não utilizar string como chave primária, correto? Mas no meu caso, se eu utilizar por exemplo cpf, cnpj, como chaves, perderia muito no desempenho?

#8