Discussion :

[coshibe]

Bnjour me revoilà à programmer après une longue pause et je galère un peu. Mon problème est que je dois créer une classe personne(instanciable) et une classe client qui doit pouvoir avoir plusieurs entités pour une meme personne. Pour etre plus clair, une personne peut avoir plusieurs entités clients mais un client n'est reliè qu'à une personne. j'ai donc décidé de faire une mappedsuperclass AbstractPersonne de sorte que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
@MappedSuperclass
@Table(name = "PERSONNE")
 
public class AbstractPersonne   {
@Id
private String Id;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
@Entity
public class Personne extends AbstractPersonne

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
@Entity
@Table(name="T_CLIENT")
public class Client extends AbstractPersonne {

Et là ou ej coince vraiment c'est que j'ai besoin de compléter la clé dans clients avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
@Entity
@Table(name="T_CLIENT")
public class Client extends AbstractPersonne {
@Id
private String NumClient;

mais du coup hibernate considère que je la clé est juste NumClient et je deviens dingue. @Inheritance ne marche aps car les tables sont imposées donc pas de discriminator possible.

Quelqu'un a une idée de comment m'en sortir pour faire cette clé composée pour dans ma classe client en appelant une partie depuis la mappedSuperClass?

[professeur shadoko]

au niveau du principe: est-ce vraiment correct de faire que Client hérite de Personne?
Une délégation serait mieux venue qu'un héritage ..... et donc on aurait une table Client qui référencerait une Personne

[OButterlin]

Idem pour moi... le client référence une personne, il n'en hérite pas...

Pour la mise en oeuvre, je te conseille d'utiliser des clés primaires non parlantes (un incrémental est idéal) dans ta table Client et Personne...
En fait, je te conseille d'utiliser des clés primaires de ce genre tout le temps

[coshibe]

J'ai mis un peu de temps à répondre parce que je ne conaissais pas la délégation, ca c'est fait et j'ai l'impression que la délégation ne va pas pas pouvoir s'appliquer dans mon cas, apparement la délégation c'est surtout pour étendre en one to one.
Par contre pour les clés non parlantes j'ai du mal à trouver de la doc, concretement je dois juste faire une référence à Personne dans ma classe Client c'est bien ca?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
@Entity
@Table(name="T_CLIENT")
public class Client  {
@Id 
private String NumClient;
@Id
private String PersonneId;
 
private Personne p;

[OButterlin]

Pour les clés non parlantes type auto-incrément, la plupart des bases de données actuelles sont capables de le gérer, soit via une "séquence" (Oracle), soit directement sur la définition de champ id (MySQL, DB2)
Dans le cas 2 (le plus simple), tu crées ta table comme ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
CREATE TABLE MA_TABLE (   
  UID INTEGER AS IDENTITY NOT NULL,
  ...
  PRIMARY KEY(UID)
};

Pour la séquence, regarde ici...

Le principal avantage de ce type de clé, c'est de faciliter la référence externe et de s'abstraire de toutes contraintes sur les types de champs dans le cas de clés composites.
Exemple :
- une table Adresse, clé primaire [CODE CHAR(5), TYPE Integer]
- une table Client, qui référence une adresse (elle contient donc 2 champs pour ça, un pour CODE, l'autre pour TYPE)

Si la clé d'adresse change, il faudra modifier toutes les tables qui la référencent.
Avec une clé numérique auto-incrémentée, seule la recherche d'une adresse sera impactée, une fois l'adresse trouvée, on utilise juste son UID.
Même si le champ CODE passait de CHAR(5) à CHAR(10) ou si on ajoutait un troisième champ dans la clé primaire d'Adresse, la référence (et donc toutes les tables qui la référencent) resterait inchangée.

Bref, pour moi (et bien d'autres), il y a 2 types de clés :
- la clé primaire qui identifie un enregistrement d'une table et qui sert à référencer un enregistrement externe (foreign-key)
- la clé "fonctionnelle", qui peut être unique aussi, qui sert à trouver un enregistrement de manière plus naturelle, mais qui ne devrait pas servir à référencer un enregistrement externe

[coshibe]

Merci Obutterlin,

Je comprends mieux ce qu'est une cle non parlante. Malheureusement l'ERP sur lequel je travaille ne me laisse pas cette liberté. Ma clé c'est "NUDOSS + NULIGN" et je ne peux pas changer ca. Je pense que je vais oublier l'heritage et utiliser une clé embarquée ce sera sans doute plus simple de ce que je vois.