Discussion :

[perdeak]

Bonjour,

Voilà mon problème, j'ai une table avec des références produits, leur quantité en stock, leur vente par trimestre.
A la fin de mon résultat j'aimerai une ligne avec: "Total, la somme de toutes les références, la somme des vente par trimestre...".

Comment puis je rajouter ça en fin de requête ? Avec un Join mais de quel type pour qu'une seule ligne soit créée en fin de requête ?

[StringBuilder]

Bonjour, alors deux éléments de réponse :

1/ C'est pas au SGBD de s'amuser à faire des lignes de total : t'as déjà toutes les informations dans ta requête, donc tu peux parfaitement faire des cumuls avec ton programme appelant pour éviter de relire les données une seconde fois pour rien.

2/ Si tu ne veux pas tenir compte du mon 1/, du peux trouver ton bonheur en faisant un "UNION" et la même requête avec des SUM() ou COUNT() sur tes différents champs.

Code :

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

1
2
3
4
5
select 'détail' as col, code, stock, ventes
from produits
union
select 'total', count(*), sum(stock), sum(ventes)
from produits

[Oishiiii]

En fonction du SGBD et de sa version, vous pouvez utiliser l'option ROLLUP de la clause GROUP BY.

[perdeak]

Ok merci j'arrive bien à rajouter ma ligne, mais elle sort en plein milieu des autres résultats, je n'arrive pas à classer le résultat, en essayant le tri sur le premiere requete ça ne marche pas et sur la deuxième non plus...

[Oishiiii]

Essayez de nous fournir la structure de/des table(s) au format SQL (CREATE TABLE..) ainsi qu'un jeu d'essai (INSERT INTO...).
Montrez-nous le résultat que vous attendez.
Indiquez-nous le SGBD aussi

C'est pas évidant d'aider avec si peu d'information.

[StringBuilder]

en vous basant sur ma requête, si vous ajoutez bien le champ "détail"/"total" en première position, vous pouvez faire un "order by 1" : total étant alphabétiquement après détail, la ligne de total sera rejetée à la fin

[perdeak]

Mon order by doit il porter sur la première partie (avant le UNION) ou après ?

[StringBuilder]

A la fin de la requête.

Si je ne m'abuse, le order by s'applique de toute façon à l'ensemble du résultat.

PS : Si tu utilises un UNION ALL, ça devrait aller (à peine) plus vite, et en plus tu devrais peut-être pouvoir te passer du order by;

[perdeak]

Effectivement avec un Union ALL je me passe de mon Order by de fin. En revanche je garde mon order by de premier moitié de requête. Je vous remercie, ça m'enlève une épine du pied.

[al1_24]

Si tu utilises un UNION ALL (...) tu devrais peut-être pouvoir te passer du order by;

Il n'est pas assuré que cela fonctionne.
Selon la norme SQL, seule la clause ORDER BY peut assurer l'ordre des lignes retournées par une requête.
Ni la clause GROUP BY, ni l'ordre d'insertion des lignes, ni la clé primaire (pour ne citer que les idées reçues le plus couramment énoncées) pas plus que l'ordre des sous-requêtes avec UNION ne devraient influer sur l'ordre des lignes en l'absence de clause ORDER BY.

[StringBuilder]

Je suis en effet d'accord sur ce point.
En revanche, dans la pratique (et ça s'explique très facilement), lorsqu'on utilise UNION ALL (et uniquement ALL) le SGBD va exécuter les requêtes une à une et concaténer les résultats sans faire de traitement supplémentaire.
Donc à moins que le SGBD décide tout d'un coup d'exécuter les requêtes de base en haut ou dans un ordre anarchique (bon, vous avez raison, ça reste possible) le résultat de la dernière requête sera toujours en dernier.
En revanche, si on fait un UNION sans le ALL (donc DISTINCT), à ce moment, le SGBD trie généralement les lignes au moment du UNION pour détecter plus facilement les doublons (même fonctionnement que pour le GROUP BY qui trie les lignes) et dans ce cas, effectivement, tout peut très bien se retrouver mélangé.

Attention à un point tout de même : visiblement, la requête contient un ORDER BY avant le UNION (à ma connaissance, c'est pas SQL compliant). Du coup, c'est qu'on est sur un SGBD qui conserve l'ordre des blocs UNION (sinon, faudra m'expliquer comment il fait pour trier de façon différentes des lignes mélangées)

[al1_24]

à moins que le SGBD décide tout d'un coup d'exécuter les requêtes de base en haut ou dans un ordre anarchique (bon, vous avez raison, ça reste possible)...

C'est ainsi que travaillent les SGBD à traitement massivement parallèle (MPP), qui vont faire calculer par des processus différents des parties de la requête sur des portions de données avant de rapatrier tous les résultats... dans l'ordre où ils arrivent.