je met quoi dans le GROUP BY ? J'ai tester avec : GROUP BY pat.nip.
Sinon voici les résultats obtenu :
- Requête originale :
- Requête simplifier :
Version imprimable
je met quoi dans le GROUP BY ? J'ai tester avec : GROUP BY pat.nip.
Sinon voici les résultats obtenu :
- Requête originale :
- Requête simplifier :
Le principe général est que le GROUP BY doit contenir toutes les colonnes du SELECT qui n'ont pas d'opérations de regroupement (SUM, MAX, MIN, AVG, COUNT).
En reprenant la proposition de tbc92, ça donnerait ceci, si Oracle veut bien grouper par les alias des colonnes du SELECT :
Le test à faire avec ce début de requête, c'est de voir si les deux colonnes calculées (les MIN(CASE...) sont bien renseignées.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Ensuite il suffit d'appliquer le même principe sur le reste de la requête.
les alias ne fonctionnent pas :
Code:ORA-00904: "ETB" : identificateur non valide
Bon, déjà ça :
à l'air de fonctionner.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
C'est bizarre qu'il ne commence à tiquer qu'au dernier alias ! Tu es sûr que tu as bien repris identiquement l'alias de la colonne du SELECT dans le GROUP BY ?Citation:
les alias ne fonctionnent pas
Citation:
ORA-00904: "ETB" : identificateur non valide
Si oui, alors essaie avec les numéros de colonnes :
12 colonnes avant le premier MIN donc :Code:
2
3
4
5
6
7
8
9
10
11
12
13
Si ça ne fonctionne pas alors il faut reprendre le détail du SELECT :Code:GROUP BY 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
Code:GROUP BY pat.nom, pat.sexe, pat.nip, SUBSTR(datenais, 1, 4), SUBSTR(datenais, 5, 2) -- etc. Je sais, c'est chiant !
Merci, finalement ça à l'air de fonctionner avec ceci :
- Le GROUP BY est correct ?Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
- Peut-on vérifier que deux requêtes sont identique ?
- Peut-on vérifier les performances des deux requêtes ?
- y'a t-il d'autres amélioration pour simplifier la requête ?
Je n'ai pas vérifié par rapport à la requête d'origine mais la nouvelle semble correcte.
Oui, le GROUP BY semble correct puisqu'il reprend les colonnes du SELECT qui ne contiennent pas de fonctions de calcul.
Est-ce encore simplifiable ? Je ne sais pas.
Côté performances, testez vous-même la différence entre les deux requêtes sur le même jeu de données.
S'il y a peu de données, la différence ne sera pas significative mais s'il y en a beaucoup, je parierais pour une victoire de la nouvelle requête.
Si le résultat de cette requête doit être affiché par une application, j'aurais plutôt récupéré les données davantage en brut et traité l'interprétation dans le langage de programmation de l'application. Cette requête ressemble en effet bigrement à de la cosmétique, ce qui n'est pas le boulot du SGBD.
Effectivement c'est de la cosmétique. Mais le code Java qui traite le résultat derrière est très simple :lol:
Ben comme l'explique SQLPro dans son cours SQL, pas sûr du tout que ce soit le bon choix !
S'il y a très peu de données, ça ne pénalisera pas l'utilisateur mais s'il y a des centaines de milliers de lignes ou encore davantage, il finira par avoir le temps d'aller boire un café avant de voir le résultat.
c'est une requête qui s'effectue la nuit.
Je vais voir pour supprimer tous les 'decode' ainsi que les colonnes inutiles.
J'en profite pour poser la question, y'a t-il des fonctions/tuto pour faire l'équivalent des decode, substr etc ... en java ?
DECODE, c'est en quelque sorte un switch. Si telle valeur en entrée alors telle valeur en sortie.
SUBSTR doit bien avoir son équivalent en Java comme dans n'importe quel autre langage parce que ça fait partie des fonctions texte de base.
DECODE c'est la vieille version de CASE WHEN THEN ELSE END.
C'est un simple IF.
Quand il y a plusieurs erreurs dans une requête, Oracle signale la dernière erreur, et non la première... C'est surprenant, mais c'est comme ça.Citation:
Envoyé par CinePhil
La dernière requête proposée me paraît optimisée.
Maintenant, tu as un seul SELECT au lieu de 40 ou 50 SELECT imbriqués.
Tu as dû diviser le temps de traitement par 5 au minimum, et probablement beaucoup mieux.
L'étape suivante serait éventuellement d'utiliser les Hints, pour aider Oracle à choisir le bon plan d'exécution, et les bons indexes.
Mais si Oracle s'en sortait avant, il devrait s'en sortir maintenant.
Mon premier objectif est de simplifier la requête pour pouvoir la comprendre et éventuellement la modifier.
L'optimisation ne m’intéresse pas, cette requête est lancé une fois par jour (la nuit) et prend moins d'une seconde (une dizaine de ligne comme résultat).
Juste comme ça : je pense qu'il est impératif de comprendre la requête dans son intégralité AVANT de chercher à la simplifier.
Sinon, c'est le meilleur moyen de produire des bugs !
Effectivement.
Et sur cet exemple, la requête de départ était si compliquée... Même si sur tes premiers tests, tu obtiens la même chose avec les 2 requêtes, rien ne garantit que les 2 requêtes soient strictement équivalentes.
En particulier le cas des données manquantes. si un code Nipatient est présent dans une table mais pas dans l'autre, les résultats sont-ils les mêmes ???
Éventuellement, construis une base de test avec des jeux de données volontairement tronqués (données manquantes dans la table C_QUESTION par exemple), et vérifie si les 2 requêtes donnent la même chose.
Et en cas de différence, fais valider par ton 'client' laquelle des 2 requêtes donne le résultat voulu.
Concernant la restriction sur la date :
est-ce la bonne manière de faire ? Comme récupérer sur plusieurs jours ? Avec un BETWEEN ?Code:substr(RDV.DATE_RDV, 1, 8) = to_char(sysdate + 1, 'yyyymmdd')
Non ce n'est pas la bonne manière de faire.
Quel est le type de la colonne DATE_RDV ?
DATA_TYPE : NUMBER(12, 0)