design many to one

Salut,
J'ai des objets de types variés qui n'ont pas de relation d'héritage, on va dire type A B C ... T.
Tous ces objets peuvent contenir plusieurs listes d'objets de type X, mais chaque X peut être lié qu'a un seul type, et une seule fois.

maintenant au niveau design je me demande comment procéder

du côté des types A ... T c'est plutot simple, ça va donner par exemple

Code:

---

1 2 3 4 5 6 7 8 9 10

class A { Set<X> l1; Set<X> l2; Set<X> l3; }   class T{ Set<X> l1; Set<X> l2; }

---

maintenant de l'autre côté, pour x ça me parait bourrin de faire

Code:

---

1 2 3 4 5 6 7 8 9 10

class X { A a1; A a2; A a3; . . . T t1; T t2; }

---

Ce qui potentiellement ferait un type X dont la table mappée aurait plein de colonnes pour les foreigns keys vers tous les types.

Avec des tables d'associations ça serait un peu moins choquant, mais ça ferait toujours pas mal de tables, et je me retrouve toujours avec un type X lié plein d'autres types, même si il peut jamais être lié à plus d'un à la fois.
Du coup ça serait horrible, niveau perfs, vu que pour charger un objet de la table X, j'imagine que hibernate irait chercher dans TOUTES les tables d'association pour remplir les champs a1, a2 ... t1,t2 ...


après je pensais à résoudre ce problème des dépendances de X à plein d'autres objets en utilisant l'héritage.
donc faire un objet pour chaque liste

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class XA1 extends X{ A l1; }   class XA2 extends X{ A l2; }   class XA3 extends X{ A l3; }

---

mais bon ça ferait faire quinze mille classes :aie:
même si en terme de code écrit ça ne rajoute que la définition de la classe, vu que mes annotations sur les getters devront exister quoi qu'il arrive

je pourrais toujours factoriser un poil comme ça

Code:

---

1 2 3 4 5 6

class XA extends X { A a1; A a2; A a3; }

---

donc je me demande ce qui est préférable ou recommandé par hibernate