Mapeando PK como FK

Opa Gean

eu acho essa solução Id e FK a melhor.
Uma outra opção é vc nao fazer o JoinColumn. Daí, o persistence vai criar uma tabela cliente, uma tabela pessoa, e no meio, uma tabela cliente_pessoa, que terá somente as PK deles, e ainda uma PK de controle interno dele.

Abraços

Queria saber pq vc precisa fazer assim.
Cliente herda de Pessoa?
Vc quer que suas tabelas fiquem organizadas de qual forma?

Eu normalmente prefiro que seja criada uma tabela para cada entidade filha e não apenas uma tabela para a entidade pai que indique nos seus atributos a instancia correspondente da filha.

Para fazer como eu disse (uma tabela para cada filho), faça o seguinte:

@MappedSuperclass
public abstract class Pessoa implements Serializable {

    @Id
    @GeneratedValue
    private long id;
    
    // outros campos...

}

@Entity
public class Cliente extends Pessoa {
    
    // note que o id vai ser herdado de Pessoa
    // aqui vem os atributos específicos de Cliente

}

Nisso vc vai ter uma chave artificial para Cliente (que é o id herdado de pessoa). Ai para garantir a unicidade do Cliente vc pode definir o atributo CPF por exemplo que seja unique. Eu sempre opto por usar chaves artificiais (os ids da vida) para fazer com que o desempenho seja melhor.

Se não quiser fazer como fiz (ou seja, criar apenas uma tabela), basta usar herança normalmente.

[]´s

Concordo com o David.

Até porque, qdo vc não usa os “Ids da vida”, mesmo utilizando JPA, EKB ou outro tipo de controle de persistência que não seja manual, quando vc precisar (se precisar) utilizar SQL nativo (a gente nunca sabe), fica dificil vc selecionar campos q não contenham especificação própria.

blz? abnraços