Discussion :

[Noob_si]

Bonjour,
Je cherche une astuce pour minimiser une requête que je dois faire car très limité en nombre de caractères qu'importe le langage, l'essentiel étant dans l'approche.

L'idée est de remplacer des "sous-select" par des jointures et des conditions permettant d'être fin dans le code.

Je dois interroger un formulaire d'une base de données de mon logiciel métier dans lequel il y a des boutons-radios.

Je suis arrivé à "minimiser" les choses dans la clause FROM et à trouver les réponses à la question 1, mais je ne sais ensuite pas comment dire dans les autres clauses je veux lire les réponses à la question 2 etc.

Notez que la requête citée ici est en HQL

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
SELECT 
data1.caud_libelle as question1, data2.caud_libelle as question2
 
FROM
Frm_instance_formulaire as fifo
join fifo.frm_formulaire as form
join fifo.frm_instance_rubriques as irub
join irub.frm_valeurs as valeur1 
join irub.frm_formulaire_rubrique as rub1 with rub1.foru_code = 'QUESTION1'
join irub.frm_formulaire_rubrique as rub2 with rub2.foru_code = 'QUESTION2',
 
Bas_catalogue_util_data as data1
 
WHERE 
form.form_code = 'code_formulaire'
and valeur1.fval_id_objet = data1.id

Je sais bien que mon problème se situe autour de la jointure externe "Bas_catalogue_util_data as data1", mais je ne sais pas comment formuler la chose.

Je m'en sors facilement avec 2 sous-select contenant les instances de rubriques et cette jointure externe mais je suis persuadé qu'il y a mieux et plus puissant.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
SELECT
(select data1.caud_libelle from fifo.frm_instance_rubriques as instrub1 
join instrub1.frm_formulaire_rubrique as frub1 
join instrub1.frm_valeurs as valrub1, 
Bas_catalogue_util_data as data1 where valrub1.fval_id_objet = data1.id
and frub1.foru_code = 'QUESTION1') 
(select data2.caud_libelle from fifo.frm_instance_rubriques as instrub2 
join instrub2.frm_formulaire_rubrique as frub2 
join instrub2.frm_valeurs as valrub2, 
Bas_catalogue_util_data as data2 where valrub2.fval_id_objet = data2.id
and frub1.foru_code = 'QUESTION1') 
 
 
FROM 
Frm_instance_formulaire as fifo
join fifo.frm_formulaire as frm
 
 
WHERE
and frm.form_code = 'code_formulaire'

Si vous pouviez m'aider à avoir la logique manquante...

Je vous remercie.

[Waldar]

Ma boule de cristal m'indique que vous devriez chercher du côté de PIVOT.
Je serait étonné que cet opérateur soit implémenté en HQL, mais la logique avec des max(case) est elle valable quel que soit le SGBD.

[CinePhil]

Bizarres ces jointures sans condition de jointure !

Syntaxe de la jointure :

Code :

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

1
2
FROM table_1 AS t1
JOIN table_2 AS t2 ON t1.une_colonne_de_table_1 = t2.une_colonne_de_table_2

[Noob_si]

Bonjour,
Il ne semble en effet pas que PIVOT soit connu dans HQL.
Je n'ai pas compris "la logique entre les max(case)" en revanche, j'ai choisi une solution de facilité : éviter la jointure externe et faire un CASE WHEN THEN ELSE END qui permet de convertir le fval_id_objet en réponse attendue.

C'est peut-être pas encore propre mais ça semble fonctionner.

[escartefigue]

Bizarres ces jointures sans condition de jointure !

Je crains qu'il s'agisse d'un NATURAL JOIN à corriger d'urgence si c'est bien le cas !

[CinePhil]

Ou pire : des produits cartésiens de tables !

[Noob_si]

Bizarres ces jointures sans condition de jointure !

Syntaxe de la jointure :

Code :

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

1
2
FROM table_1 AS t1
JOIN table_2 AS t2 ON t1.une_colonne_de_table_1 = t2.une_colonne_de_table_2

Pour la syntaxe des jointures elle est correcte. Comme je l'ai indiqué, j'interroge la base de données d'un logiciel métier et c'est comme ceci que doivent être écrites les jointures selon l'éditeur.

C'est surtout l'approche que je cherche.

[escartefigue]

La syntaxe est correcte, sans doute s'il n'y a pas de messge d'erreur, mais comment HQL fait il la distinction entre les différents types de jointure Mystère...

La doc ici (chapitre 14.3) me laisse perplexe sur ce point

[CinePhil]

HQL : langage de requête d'Hibernate, un Outil Réellement Merdique que j'ai eu le déplaisir de devoir utiliser il y a quelques années.
J'avais à l'époque posté une discussion sur ma difficulté à réaliser une requête un peu complexe avec ce machin et j'ai fini par écrire la requête en SQL en 1/4 d'heure et l'ai balancée directement à Hibernate parce que j'avais enfin trouvé une syntaxe qui permettait de le faire.

J'avais aussi constaté dans les logs qu'Hibernate lançait en fait beaucoup de requêtes pour pas grand chose et parfois plusieurs fois la même.

Je ne sais pas si ça s'est amélioré depuis mais plutôt que de s'emmerder avec un tel outil et apprendre une nouvelle syntaxe dérivée du SQL, autant utiliser directement SQL. C'est plus propre, plus performant.

[escartefigue]

Ca résume assez bien ce que je pense des générateurs de langage en général : sous prétexte de faciliter la vie au développeur, ça dégrade le code au détriment de la maintenance et des performances et rend l'entreprise dépendante d'un générateur souvent peu répandu pour lequel trouver des compétences est difficile.

A mon sens, il vaut mieux former et accompagner les développeurs plutôt que de tomber dans ce genre de piège !

[SQLpro]

De toute façon Hibernate n'étant pas doté d'un optimiseur, faire des requêtes HQL en pensant les optimiser n'est que pure utopie....

On peut optimiser du SQL par différents moyens :
1) modéliser correctement la base en appliquant strictement les formes normales
2) rajouter autant de contraintes que possible, y compris validation (CHECK)
3) indexer les données des tables
4) rajouter des statistiques particulières
5) récrire les requêtes différemment avec d'autres opérateurs
6) rajouter des objets systèmes faisant de la redondance automatique (vues matérialisées/indexées, colonnes calculées, déclencheurs de précalculs...)
7) utiliser les techniques modernes des SGBDR ("in memory", procédures compilées natives, indexation verticale "columstore"....)
8) dans les cas extrêmes, utiliser des "tags" de requête
Mais on ne peut pas optimiser quelque chose qui n'est pas doté d'un optimiseur !

A +

[escartefigue]

Tout à fait d'accord et

09) choisir avec soin les index cluster
10) supprimer les index inutiles
11) surveiller la fragmentation
12) choisir le bon niveau d'isolation et de verrouillage
13) privilégier autant que possible les logiques ensemblistes plutôt que les curseurs

[SQLpro]

...12) choisir le bon niveau d'isolation et de verrouillage

Oui, mais là le choix ne dois pas être fait en considération des performances, mais simplement sur le fait de la logique, sinon cela pourrait conduire à des résultats de requête faux.

A +