Discussion :

[aurelientp]

Bonjour.
J'ai une classe "COMPETENCE" mappée qui contient une quinzaines d'attributs et surtout plusieurs collections. Pour le moment, toutes mes requêtes sont sans SELECT (je récupère donc directement un objet COMPETENCE).

Je n'ai bien évidemment pas besoin de tous les attributs ni de toutes les collections à chaque traitement : par exemple, pour une requête, je ne vais utiliser que deux attributs. Je me pose donc la question d'utiliser des objets restreints, qui ne contiendraient qu'un nombre limité d'attributs en fonction de mes besoins. Ex : COMPETENCE_CODELABEL serait un objet qui contiendrait uniquement le code et le label de la compétence.

Donc j'utiliserais une requête du type "SELECT code, label FROM competence ..." mais le résultat de cette requête sera une liste de COMPETENCE_CODELABEL. Comment le spécifier car il n'y aura pas de mapping direct avec la bdd, donc pas de hbm.xml ?

Merci d'avance

[fr1man]

A partir du moment ou tes collections sont lazy, je ne vois pas l'intérêt de multiplier les objets pour limiter le nombre d'attributs récupérés.
Tu ne gagneras à mon avis, pas grand chose en perf, si c'est ce que tu recherches.

[djsnipe]

Tu peux également utiliser la syntaxe suivante sans avoir besoin d'un HBM supplémentaire :

Code :

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

1
2
3
4
5
6
SELECT 
   new com.blabla....MonObjet(code, label)
FROM 
   competence
WHERE
   ...

Tu auras directement à disposition des objets "MonObjet". Il faut cependant bien s'assurer que MonObjet à un constructeur avec comme paramètres ceux associés aux types spécifiés dans la requête : code et label dans l'exemple.

Concernant les perfs, je pense que ce sera quand même un mieux. D'un part si tes collections ne sont pas lazy effectivement, et d'autre part sur le volume de données brutes qui sont échangées entre la base et le programme Java. Et là, si le nombre d'attributs diminue sensiblement, tu peux avoir de beaux gains. D'un point de vue réseau il y a donc une économie, c'est toujours ça. D'un point de vue BDD, tu allège très peu le traitement, mais tu peux tomber dans des cas où toutes les données souhaitées sont dans un index, et donc sans recherche dans un segment de data.
Le seul gros inconvénient de l'approche, c'est la compléxité et la maintenabilité du code associé. Il y a beaucoup de code pour gérer, peut être, de micro optimisations en regard du reste du code.

[aurelientp]

Merci pour vos réponses.
Je vais essayer de mettre ce traitement en place sur les requêtes dont le rapport "attributs récupérés"/"attributs utilisé" est le plus important.
Ca me permettra de voir si les améliorations au niveau performance sont au RDV.
Encore merci.