Pourquoi éviter ORDER BY avec des positions ordinales en SQL ?

ORDER BY 1, 2, c’est tentant mais terriblement risqué en SQL. En clair, ça nuit à la lisibilité et casse les requêtes quand la structure évolue. Découvrez comment et pourquoi préférer les colonnes nommées pour un code propre et fiable.

3 principaux points à retenir.

Lisibilité : Ordinal positions rendent les requêtes obscures.
Fragilité : Modifier le SELECT casse ou change le tri.
Maintenance : Risque d’erreurs quand la structure de données évolue.

Qu’est-ce que l’ORDER BY avec des positions ordinales en SQL

L’ORDER BY avec des positions ordinales, qu’est-ce que c’est donc ce truc ? C’est simple comme bonjour. Lorsqu’on utilise la syntaxe ORDER BY suivie de numéros, comme par exemple ORDER BY 1, 2, on indique à SQL de trier les résultats selon les colonnes qui figurent à ces positions. Oui, vous avez bien compris : on parle ici de positions dans le SELECT, et non des noms de colonnes. Cela peut sembler divertissant, mais vous allez vite comprendre pourquoi il y a une polémique autour de ce sujet.

Quand vous écrivez ORDER BY 1, vous reconnaissez que vous voulez trier par la première colonne de votre jeu de résultats. ORDER BY 2 signifie que vous voulez le tri par la seconde colonne. Pratique, non ? Oui, si l’on veut faire le malin. Mais prenons un exemple concret pour que ça devienne palpable.

Comme on dit à Brive, un bon plan de marquage vaut mieux qu’un bon reporting ! Si besoin, consultez moi - faites appel à un super consultant en tracking client et server side.

SELECT nom, age, salaire
FROM employes
ORDER BY 1, 2;

Dans cet exemple, les employés seront triés d’abord par leur nom (première colonne), puis par leur âge. Imaginez que votre colonne nom ait des doublons, alors SQL triera par âge pour trancher. Ça fait un peu naïf, non ?

Maintenant, regardons une approche plus explicite :

SELECT nom, age, salaire
FROM employes
ORDER BY nom, age;

Avec cette syntaxe, les intentions sont claires. Pas de confusion sur ce qui est trié, vous êtes dans le feu de l’action avec des noms de colonnes bien définis. Alors pourquoi cette syntaxe abrégée existe-t-elle ? Eh bien, son origine remonte à des systèmes SQL plus anciens où l’on voulait alléger les requêtes pour parer à des limitations.

Mais comme dans toute bonne histoire, il y a un revers à la médaille. Nombreux sont ceux qui, lorsqu’ils relisent leur code après quelques mois (ou années !), ne se souviennent plus de ce qu’ils entendaient par la fameuse position 2 ou 3. En gros, cela mène souvent à des drames de la lisibilité, un vrai casse-tête pour le développeur du futur !

Alors, la prochaine fois que vous pensez à utiliser l’ORDER BY avec des positions ordinales, demandez-vous si la clarté n’est pas préférée à la concision. Et si vous voulez vraiment creuser le sujet, regardez cet excellent article sur le ORDER BY.

Quels sont les risques d’utiliser ORDER BY avec positions ordinales

Pourquoi cette pratique est-elle déconseillée, me demandez-vous ? Parce qu’utiliser ORDER BY avec des positions ordinales dans SQL, c’est comme mettre des œillères avant de monter sur un cheval de course. On perd de vue la course entière, et seul l’instant présent compte. Un instant, qui à terme peut nous jouer des tours.

Commençons par la perte de lisibilité du code. Quand on écrit une requête SQL, le but est de rendre la vie facile, non ? En utilisant des positions ordinales, on peut oublier de quoi on parle. Que se passe-t-il quand on décide d’ajouter ou de retirer une colonne dans notre SELECT ? Et bien, la requête peut continuer à fonctionner, mais les résultats ne correspondront plus à nos attentes. Le bon vieux SELECT column1, column2, column3 ORDER BY 2 pourrait se transformer en un joli bruit de bottes sans prévenir. Plus personne ne sait à quel saint se vouer !

À ce propos, imaginez que l’on ait une requête qui retourne des noms et des âges, puis que l’on décide d’ajouter une colonne pour les adresses :

SELECT name, age, address FROM users ORDER BY 2;

Maintenant, le ORDER BY 2 ne trie plus par l’âge, mais par l’adresse, sans que quiconque n’ait changé la commande. Surprise ! Vous avez bien travaillé, mais vos résultats ressemblent plus à un charivari qu’à une pièce de théâtre soigneusement orchestrée.

Erreur silencieuse, voilà un fléau. Si l’ordre de vos colonnes change, la moindre petite correction peut entraîner des résultats complètement inattendus. La maintenance devient alors un véritable casse-tête. Quand plusieurs personnes travaillent sur le même code, il suffit d’un novice qui modifie l’ordre des colonnes et tout s’écroule. Une véritable danse d’ombres, où chacun risque de marcher sur les pieds de son voisin.

Les experts SQL ne sont pas en reste pour prévenir cette pratique. Voici un article qui souligne les dangers de cette approche. Une recommandation de bon sens, comme on dit en cuisine : le diable se cache dans les détails ! Ne laissez pas une petite position ordinale saboter votre œuvre magistrale.

Comment améliorer ses requêtes ORDER BY pour éviter ces écueils

Ah, les requêtes SQL ! Elles sont comme une belle pièce de théâtre : parfois, vous avez des acteurs talentueux, mais d’autres fois, c’est le fiasco total. Et s’il y a bien une chose à éviter dans cette pièce, c’est l’utilisation d’ORDER BY avec des positions ordinales. Ne vous y trompez pas, on ne parle pas de choisir un bon mouchoir, mais de simuler un numéro de cirque qui finit mal. Utiliser des numéros de colonnes, c’est prendre un risque inutile.

Alors, quelle est la bonne pratique ? Utiliser les noms réels des colonnes dans votre clause ORDER BY. Pourquoi, me direz-vous ? Parce que c’est beaucoup plus robuste et clair. Supposons que vous ayez une table appelée Clients et que vous souhaitiez trier par Nom. Voici comment ça devrait se faire :

SELECT * FROM Clients ORDER BY Nom ASC;

À ce stade, l’ordinateur sait exactement de quoi on parle. Les noms de colonnes sont explicites, et quand vous relisez votre code, vous n’avez pas à vous gratter la tête en vous demandant « Qu’est-ce que le 2 ici encore ? ».

Pour vous aider à mieux comprendre cette distinction entre le litéral et ordinal, voici un mini-guide comparatif :

Lisibilité :
- Litéral : Très clair, qu’on soit le rédacteur ou le relecteur.
- Ordinal : Un vrai casse-tête, surtout sur les requêtes complexes.
Maintenance :
- Litéral : Facile à modifier sans casser l’ensemble.
- Ordinal : Tout changement peut impliquer une réécriture intégrale.
Risques :
- Litéral : Moins d’erreurs possibles, comparable à un bon plat dont on connaît tous les ingrédients.
- Ordinal : Prendre des risques, comme s’aventurer sur un fil de fer en plein spectacle.

Et pour coder propre en SQL, quelle stratégie adopter ? Voici quelques conseils pratiques :

Tests : Toujours tester vos requêtes, surtout celles qui contiennent des ordres de tri.
Relecture : Une bonne relecture évite bien des maux – la fatigue de coder peut brouiller votre vue.
Documentation : Une documentation claire sur le pourquoi du comment de votre code est toujours bienveillante.

Pour ceux qui cherchent à valider ou détecter les problèmes liés à l’usage d’ordinals, explorez des outils comme Data Bird qui peuvent rendre votre vie beaucoup plus simple.

En résumé, devant l’inévitable dramaturgie des ordres, n’ayez pas peur de poser les bonnes questions et d’opter pour la clarté. L’honnêteté intellectuelle en SQL, c’est comme un bon plat : on préfère voir les ingrédients que de se demander ce qu’il y a sous la croûte.

Alors, pourquoi prendre le risque avec ORDER BY 1, 2 quand on peut faire simple et sûr ?

Utiliser ORDER BY avec des positions ordinales, c’est jouer avec le feu. Ce raccourci malin sur le papier se transforme souvent en cauchemar lors de modifications ou maintenances. Privilégier les noms de colonnes garantit lisibilité, prévisibilité et robustesse. Au final, votre SQL reste clair, vos résultats fiables, et votre travail gagne en qualité et sérénité. Le vrai bénéfice ? Un code qui ne trahit pas vos efforts, même dans le temps.

FAQ

Qu’est-ce que signifie ORDER BY 1, 2 en SQL ?

Cela ordonne le résultat selon la première puis la deuxième colonne sélectionnée dans le SELECT, en se basant sur la position et non le nom des colonnes.

Pourquoi ne pas utiliser les positions ordinales dans ORDER BY ?

Parce que cela rend le code peu lisible, fragile aux modifications du SELECT et peut produire des résultats incorrects si l’ordre des colonnes change.

Quels sont les dangers concrets de l’utilisation d’ORDER BY 1, 2 ?

Vous risquez de casser vos requêtes lors d’ajout ou retrait de colonnes, ou pire d’obtenir un tri qui ne correspond plus à ce que vous espériez, compliquant la maintenance et provoquant des bugs.

Comment écrire un ORDER BY sûr et maintenable ?

Utilisez toujours les noms explicites des colonnes dans ORDER BY pour clarifier l’intention et garantir la stabilité du tri, même lorsque la requête évolue.

L’utilisation d’ORDER BY avec les noms impacte-t-elle la performance ?

Non. Les moteurs SQL modernes optimisent les requêtes de façon identique, que vous utilisiez les noms ou les positions, donc privilégiez la clarté sans craindre un coût additionnel.

A propos de l’auteur

Franck Scandolera est consultant et formateur expert en Data Engineering, Analytics et SQL depuis plus de dix ans. Responsable de l’agence webAnalyste et de Formations Analytics, il accompagne les professionnels en France, Suisse et Belgique à structurer leurs données et automatiser leurs reportings. Son fort savoir-faire couvre notamment BigQuery et les bonnes pratiques SQL, indispensables pour des pipelines data robustes et exploitables. Son style clair et didactique le rend incontournable pour optimiser vos requêtes et éviter les pièges courants, notamment dans l’ORDRE BY.