Discussion :

[zizoufoot]

Bonjour,

Dans mes souvenirs, les opérateurs ensemblistes effectuent un tri lorsqu'ils assemblent(suivant l'opérateur) deux requêtes.
On peut le vérifier en faisant :

Code :

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

1
2
3
4
5
6
7
SELECT COLUMNA
FROM T
WHERE COLUMNB IS NOT NULL
UNION
SELECT COLUMNA
FROM T
WHERE COLUMNB IS NOT NULL;

Le résultat de cette Union sera la colonne A trié par ordre ASC.

J'ai cherché sur le net le fonctionnement des opérateurs ensemblistes, mais je n'ai pas trouvé.
Auriez-vous une idée ?
Travaillent-ils avec un ORDER BY ASC par défault sur l'ensemble des colonnes de gauche à droite ?

Merci

[al1_24]

Tes souvenirs ne sont pas bons...

Tant qu'une clause ORDER BY n'est pas explicitement utilisée dans une requête de consultation, le SGBD n'est pas tenu de respecter un quelconque ordre de restitution des lignes.

[zizoufoot]

Ok.

Oracle le fait, je l'ai testé.
Je ne sais pas si d'autres le font.
Je pensais, que les SGBD effectuaient un tri pour aider à éliminer les doublons sauf dans le cas des UNION ALL par ex.

Bon bah, vu qu'ils ne font pas obligatoirement un tri ASC, le sujet est résolu..

[SQLpro]

NON !

Oracle donne l'impression de le faire. mais il existe d'autres algorithmes de groupage non basés sur des tris comme le hachage.
Comme c'est l'optimiseur qui décide quel algo il utilisera et cela par rapport à des statistiques, il peut parfaitement faire un hash un jour et un tri le lendemain !

A +

[zizoufoot]

Merci pour ta réponse

Je ne savais pas du tout.
Saurais-tu où je pourrais avoir de plus amples informations par rapport à ce sujet ? Histoire d'étudier tout ça

[fsmrel]

Bonjour zizoufoot,

Dans mes souvenirs, les opérateurs ensemblistes effectuent un tri lorsqu'ils assemblent(suivant l'opérateur) deux requêtes.

Mettons les choses au point. Un opérateur ensembliste ne trie pas ! Dans le contexte des bases de données, un tel opérateur relève de l'algèbre relationnelle qui a pour vocation de nous permettre de manipuler des ensembles particuliers, les relations, et par définition un ensemble ne contient pas de doublons, sinon ça serait un sac (bag). Ça n’est pas à l’algèbre de dédoublonner, cela est seulement du ressort d’un des composants de votre SGBD. Un SGBD relationnel authentique doit systématiquement dédoublonner, transformer un sac en ensemble, sur la base d’algorithmes de plus en plus astucieux et performants au fil des ans, peut-être en triant (ou en hachant comme le fait observer SQLpro), mais tout cela est effectué sous le capot, est totalement étranger à l'algèbre et n’a pas non plus à être expliqué à l’utilisateur, qu’il s’appelle zizoufoot ou autre.

Notons qu’un SGBD adhérant à la norme SQL n’est pas si regardant et n’est pas conforme à la théorie relationnelle. Supposons par exemple que la table PIECE ait pour contenu :

PIECE
PieceId   Nom       Couleur    Ville
----------------------------------------
      1   Boulon    Bleu       Toulouse
      2   Vis       Rouge      Rennes
      3   Boulon    Rouge      Toulouse
      4   Clou      Bleu       Toulouse
      5   Clou      Rouge      Toulouse
      6   Ecrou     Vert       Bordeaux

Si l’on veut connaître les paires {Couleur, Ville}, dans le cadre de la théorie relationnelle on utilise l’opération ensembliste PROJECTION (PROJECT) qui s’écrit ainsi :

PROJECT {Ville, Couleur}

ou plus simplement (en D) :

{Ville, Couleur}

Au résultat :

Couleur    Ville    
---------------------
Rouge      Toulouse
Bleu       Toulouse
Rouge      Rennes
Vert       Bordeaux 

Conformément à la théorie, le résultat ne comporte pas de doublons, c’est un ensemble, ce qui fait qu’il peut à son tour servir d’opérande pour une autre opération ensembliste ou un ensemble complexe d’opérations (on est dans le contexte de l’algèbre relationnelle). Comment le SGBD a-t-il éliminé les doublons ? Pourquoi fait-il apparaître <Rouge, Toulouse> en tête du résultat ? Il n’a pas à vous le dire et on n’a pas à s’en soucier, puisqu’on ne s'intéresse qu'à des ensembles. Si cet ordre vous importe, c’est que vous raisonnez non pas en termes d'« ensembles » mais de « fichiers séquentiels », vous vous situez un cran trop bas : n’hésitez pas à grimper au cran supérieur.

Pour sa part, SQL nous force à raisonner en termes de sacs. Par exemple, le simulacre de projection :

Code SQL :

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

1
2
SELECT Couleur, Ville
FROM   PIECE

fournit un résultat truffé de doublons, ça n’est donc pas un ensemble mais un sac :

Couleur    Ville    
---------------------
Bleu       Toulouse
Bleu       Toulouse
Rouge      Rennes
Rouge      Toulouse
Rouge      Toulouse
Vert       Bordeaux

L’ordre dans lequel les lignes apparaissent dépend seulement de l'humeur du SGBD et de l’âge du capitaine, c’est totalement étranger à l'algèbre relationnelle.

Si en SQL vous voulez que le résultat soit un ensemble, il faudra bricoler pour simuler la véritable projection, en utilisant par exemple le mot magique DISTINCT :

Code SQL :

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

1
2
SELECT DISTINCT Couleur, Ville
FROM   PIECE

Là encore, l’ordre d’apparition des lignes dépend de l'humeur du SGBD et de l’âge du capitaine. Comme le dit al1_24 avec un grand bon sens, c’est à vous et à vous seul qu’il revient de décider de cet ordre, grâce à la clause ORDER BY, c'est-à-dire lorsque vous voulez présenter le résultat (les éléments des ensembles) à l’utilisateur au moyen d’une combo où autre objet relevant du jargon des langages informatiques.

Saurais-tu où je pourrais avoir de plus amples informations par rapport à ce sujet ? Histoire d'étudier tout ça

En épluchant les sources des nombreux moteurs de SGBD (comme Lawrence Ellison en son temps, quand il pompa sans vergogne le prototype System R d’IBM), bon courage...

[zizoufoot]

Merci pour votre réponse, claire et précise