Ca dépend de tes requêtes. Ca dépend de la logique de tes objets, ca dépends de ta db, ça dépends au final de ce que tu veux faire. Avoir trois références potentiellement nulles, c'est ok par exemple quand les trois champs ne sont pas interchangeable. Exemple dans un arbre, un champ fils gauche, fils droit et parent. Ils ont chacun un rôle précis.
C'est moins logique quand ils sont interchangeable et sans distinction. Dans ce dernier cas tu va surtout galérer sur les requêtes complexe, statistiques etc. car elle devront regarder les 3 champs à la fois.
Exemple:
trois champs b1,b2,b3
si je veux tout les A qui référencent un B donné, je dois faire
from A a were a.b1 = :b or a.b2=:b or a.b3=:b
Si tu veux tous les A qui n'ont que 2 B, ta requêtes commence à ressembler à
from A a where (a.b1 is null or a.b2 is null or a.b3 is null) and not (a.b1 is null and a.b2 is null) and not (a.b2 is null and a.b3 is null) and not (a.b1 is null and a.b3 is null)
Si tu veux trouver tous les B qui partagent un même A, ça commence à être plus coton.
Et dans toutes tes requêtes tu devras penser à mettre b1, b2 et b3 à chaque fois. Et si demain tu rajoute un b4, faudra revoir toutes tes requêtes.
D'un autre coté utiliser une liste implique une table de jointure, donc un peu de travail en plus pour le sgbd mais aussi une opportunité pour lui d'optimiser à travers ses index. Tu peux éviter les requêtes multiples (problème principal des associations hibernate) en précisant que la collection n'est pas lazy et doit être fetchée immédiatement (fetch eager). Attention quand même à se limiter à un niveau, ne pas charger toute la DB en mémoire.
Comme souvant dans les questions d'optimisation propre, il faut poser la base: si je fait un code propre et facile à suivre (dans ce cas à priori avec des listes):
- Est-ce que je constate effectivement, par mesure objective une lenteur nécessitant une optimisation?
- Est-ce que les optimisation possibles en gardant un modèle propre amène une gain suiffisant (tuning des index, ajustement des requêtes HQL, fetch eager)?
- Est-ce que j'ai des mesures objectives qui montrent qu'un schéma dégueulasse sera plus rapide
- Est-ce que le schéma cochon est la seule solution envisageable (dernier recours)
- Est-ce que le rapport gain de performances / coût de maintenance sera intéressant
la règle d'or de l'optimisation que je me garde: ne jamais chercher à optimiser agressivement quelque chose qui n'a pas d'abord démontré être un problème et n'a pas été mesuré objectivement.
Je dit pas qu'il faut coder comme un cochon sans se soucier des performances, mais il ne faut pas tomber dans l'excès inverse de chercher à tout pris à optimiser un bout de code qui en fait nous fait peut-être perdre 2s une fois par heure.
Au passage, 1 millions de lignes, c'est peanuts pour une base de données aujourd'hui, donc elle devrait pas avoir de soucis avec les jointures et les index. On parlerait de centaines de millions de lignes, on pourrait commencer à se poser des questions sur les performances des index 
Utilisation de liste ou de variable références objets, solution optimale
Répondre avec citation
Partager