ORDER BY 1,2 en SQL trie par positions ordinales, ce qui nuit à la lisibilité et fiabilité des requêtes. Préférez les noms de colonnes pour éviter des erreurs avec des modifications du SELECT. Décortiquons pourquoi cette mauvaise habitude doit disparaître.
3 principaux points à retenir.
- ORDER BY 1,2 est peu lisible et altère la maintenance du code.
- Modifier la liste SELECT casse la logique du tri et produit des résultats inattendus.
- Utiliser les noms de colonnes assure clarté, robustesse et prévient les bugs en production.
Qu’est-ce qu’ORDER BY avec positions ordinales en SQL
Quand on se penche sur la langue un peu tortueuse du SQL, on tombe irrémédiablement sur la clause ORDER BY, cet outil qui nous permet de ranger nos données comme un bibliothécaire un peu trop pointilleux. Mais là où cela devient intéressant, c’est quand on commence à manipuler les positions ordinales, cette petite astuce qui nous permet d’écrire ORDER BY 1, 2 au lieu de nommer les colonnes sur lesquelles on veut trier. Oui, c’est un peu comme prendre le raccourci pour aller à la station de métro ; ça va, mais est-ce vraiment la meilleure option ?
Techniquement, quand on utilise ORDER BY 1, 2, on indique au SGBD de trier les résultats d’une requête en se basant sur la première et la deuxième colonnes de la sélection. Cela peut paraître malin dans l’abstract, surtout au milieu d’une requête aussi longue que le trajet en bus pour aller au boulot. La syntaxe s’écrit simplement comme ça :
SELECT nom_colonne1, nom_colonne2, nom_colonne3
FROM ma_table
ORDER BY 1, 2;À première vue, c’est utilitaire et pratique. Cependant, imaginez que vous ayez renuméroté vos colonnes un jour de grande motivation. Par pure malchance, ORDER BY 1, 2 pourrait maintenant trier par des colonnes totalement différentes de celles que vous aviez en tête. Très mauvais plan !
Pour mieux illustrer cela, prenons un exemple simple. Imaginons une table qui contient des données sur les employés :
SELECT nom, age, salaire
FROM employés
ORDER BY 1, 2;
Avec cette commande, vous triez d’abord par nom, puis par age. Comparativement, si vous optez pour :
SELECT nom, age, salaire
FROM employés
ORDER BY nom, age;Vous obtiendrez exactement le même résultat, n’est-ce pas? Mais si la structure de votre table venait à changer, ORDER BY 1, 2 pourrait mener à des chaos de tri imprévisibles. Une petite citation d’Einstein vient à l’esprit : “La simplicité est la sophistication suprême.” Parfois, la simplicité peut nous amener dans des situations où nous nous perdons. Le mot d’ordre ici : pratique, oui, mais à double tranchant.
Pourquoi ORDER BY 1,2 nuit-il à la lisibilité et maintenance
Alors, pourquoi diable éviter de coder un ORDER BY 1, 2 en SQL ? La réponse est simple : la lisibilité, mon cher Watson. Imaginez un instant que vous tombiez sur une requête avec ORDER BY 1. Que pensez-vous qu’il signifie ? Un code digne d’un roman policier où l’auteur a oublié de révéler l’identité du coupable jusqu’à la dernière page ! C’est obscur, non ? En réalité, un numérotage des colonnes ne vous dit rien sur le contenu même de la requête. Il vous laisse dans l’ignorance. En revanche, un ORDER BY nom_de_colonne est tout de suite clair, limpide, et on sait exactement sur quoi on base son tri.
Ajoutez à ça le coup classique : vous avez une requête qui fonctionne à merveille, mais voilà, vous décidez d’ajouter ou de retirer une colonne de votre SELECT. Boum ! Tout à coup, ORDER BY 1 devient un véritable champ de mines. Votre tri, qui fonctionnait si bien, est désormais d’une imprécision déconcertante. Le coupable, cette fois, c’est vous, parce que vous avez laissé la porte ouverte à l’ambiguïté. Le nombre d’erreurs causées par cette habitude est sans doute incalculable.
Permettez-moi de vous donner un petit exemple concret. Si vous avez :
SELECT id, nom, age FROM utilisateurs ORDER BY 1
et que vous décidez d’ajouter une colonne email, alors votre requête devient soudainement :
SELECT id, nom, age, email FROM utilisateurs ORDER BY 1. Vous pensiez trier par id, mais en fait, vous triez par nom ! Une belle pagaille, n’est-ce pas ?
En somme, la clarté du code, c’est le nerf de la guerre. Optez pour les bonnes pratiques SQL et privilégiez la lisibilité de vos requêtes. Prenez soin à ne pas laisser vos futurs lecteurs (ou vous-même, dans quelques mois) dans le flou. Après tout, la simplicité est souvent la clé de la réussite en programmation.
Quels risques concrets dans les pipelines et bases de production
Vous savez quoi ? Utiliser ORDER BY 1,2 peut sembler séduisant, mais accrochez-vous, car derrière cette apparente simplicité se cache un véritable champ de mines, notamment en environnement de production. Imaginez que vous ayez tout codé, que vos équipes soient heureuses, et d’un coup, boum ! Les résultats tombent comme des feuilles en automne. Vous voilà confronté à une pagination chaotique, des données potentiellement erronées et surtout, une gestion des erreurs qui rivalise avec le meilleur des spectacles comiques.
Le premier risque, c’est le changement. Imaginez que vous avez une requête qui fonctionne à merveille aujourd’hui. Cependant, demain, si vous décidez de réordonner vos colonnes dans la table source, devinez quoi ? L’ordre de tri va changer, et avec lui, la fidélité de vos données. Vous croyez avoir fait le job ? Surprise, votre requête est désormais plus un mystère qu’une solution.
- Résultats erronés : Qu’ont en commun les mauvaises notes à l’école et les résultats de SQL mal triés ? Vous ne pouvez pas dire qui est coupable, mais ça fait mal au portefeuille et à l’image.
- Debug impossible : Vous êtes en train de tenter de saisir ce qui se passe, et ce tri fourre-tout ne fait qu’ajouter au chaos. Comment expliquer pourquoi l’un de vos rapports stratégiques montre une tendance où il n’y en avait pas ? Bonne chance pour dégoter ce bug invisible dont tout le monde s’étonne.
- Temps perdu : Chaque minute passée à déchiffrer ces incohérences est une minute que vous ne passerez pas à faire quelque chose d’utile. Et au final, ce temps passe souvent par les fenêtres… et par votre budget !
Pensons un instant à des cas pratiques sur BigQuery. Disons que vous avez une requête où vous récupérez des ventes, triées par montant et par date, à l’aide d’un ORDER BY 1, 2. Si, un jour, l’administrateur de la base décide de changer l’ordre des colonnes pour une raison obscure, adieu le bon vieux tri. Vous vous réveillez un beau matin avec des données de ventes triées par date, puis par un quartz aléatoire. La transformation des données devient un cauchemar, et vos équipes de données pourraient bien vouloir se pendre !
En gros, cette petite astuce d’SQL peut vous entraîner dans un vrai labyrinthe de complexité et de coûts inutiles. Pourquoi prendre le risque alors qu’il existe des solutions fiables ? Si vous voulez garantir l’intégrité de vos résultats, faites le choix d’être explicite et d’indiquer le nom des colonnes. Votre avenir (et celui de vos données) en vaut la peine.
Comment bien écrire ses ORDER BY pour éviter les pièges
Écrire ses clauses ORDER BY avec des chiffres, c’est comme choisir le vin en se basant uniquement sur l’étiquette : ça a l’air séduisant, mais on se retrouve souvent avec un goût amer. Alors, pourquoi ne pas se contenter de noms de colonnes ? La première raison est simple : la lisibilité. Qui a envie de revenir en arrière dans un code SQL pour comprendre ce que signifie ORDER BY 1, 2? Personne. À moins d’être un masochiste du code, bien sûr.
En utilisant les noms de colonnes, non seulement vous facilitez la lecture, mais vous améliorez la maintenance du code. Imaginez, un jour, votre supérieur, avec son café noir et son regard perçant, vous demande de modifier la requête. Si vous avez utilisé des numéros, vous serez dans la panade. Or, si vous avez écrit ORDER BY nom_colonne_1, nom_colonne_2, vous pouvez rectifier le tir en un clin d’œil. C’est comme une bouée de sauvetage pour un naufragé dans l’océan impitoyable des erreurs de code.
Maintenant, pour ceux qui se frottent les mains en pensant à des tris compliqués, voici quelques astuces pratiques. Utilisez des alias clairs pour réduire la confusion. Par exemple, si vous avez nom, prenom et date_naissance, soyez explicite : ORDER BY nom AS nom_client, prenom AS prenom_client. Ajoutez des commentaires si nécessaire – ça ne coûte rien et ça jette une lumière divine sur vos intentions.
Évitez aussi les colonnes calculées ambiguës. Un calcul en colonne, c’est bien, mais si vous devez l’utiliser dans ORDER BY, cela peut devenir un vrai casse-tête. Gardez le tout simple et direct. Prenons un exemple de requête SQL correctement ordonnée :
SELECT nom, prenom, date_naissance
FROM clients
ORDER BY nom, prenom;Et pour que ça soit un peu plus fun, voici un tableau synthèse des méthodes :
| Méthode | Avantages | Inconvénients |
|---|---|---|
| ORDER BY 1, 2 | Simplicité initiale | Confusion, maintenance difficile |
| ORDER BY nom_colonne | Lisibilité, maintenance facilitée | Un peu plus long à écrire |
Pour aller encore plus loin dans votre maîtrise de la clause ORDER BY, n’hésitez pas à consulter cet article captivant sur les différents moyens de trier vos données. En fin de compte, rappelez-vous : le bon tri commence par une écriture claire et sans ambiguïté.
Alors, pourquoi prendre le risque avec ORDER BY 1,2 quand on peut faire simple et sûr ?
Commander ses résultats SQL via ORDER BY 1,2, c’est jouer à la roulette russe du tri. Les gains de brièveté se paient cher en termes de clarté et stabilité. En particulier sur des projets data complexes et évolutifs, cette manière conduit à des bugs sournois et incompréhensibles. Aujourd’hui, un tri explicite par noms de colonnes est non seulement plus clair, mais aussi indispensable pour garantir la solidité des pipelines. En laissant tomber les positions ordinales, vous gagnez en robustesse, facilitez la maintenance et protégez vos dataflows. Un petit effort qui paie gros, croyez-moi.
FAQ
Qu’est-ce que ORDER BY avec positions ordinales en SQL ?
Pourquoi éviter ORDER BY 1,2 dans mes requêtes ?
Quels problèmes en production liés à ORDER BY ordinal ?
Comment écrire un ORDER BY fiable et clair ?
Y a-t-il des cas où ORDER BY 1,2 peut être acceptable ?
A propos de l’auteur
Franck Scandolera est consultant expert en Data Engineering et formateur spécialisé en SQL, BigQuery, et automatisation no-code. Fort de plus de dix ans à architecturer des infrastructures data robustes et à former des professionnels en analytics, il maîtrise les bonnes pratiques indispensables pour des requêtes SQL claires, maintenables et fiables. Basé à Brive‑la‑Gaillarde, il accompagne agences, annonceurs et collectivités dans l’optimisation de leurs pipelines et trabaille quotidiennement avec SQL, BigQuery et les outils cloud pour garantir un data management sans panne ni surprise.
