Utiliser ORDER BY avec des positions ordinales (ORDER BY 1, 2) en SQL est une mauvaise idée. Moins lisible et fragile, cette méthode peut provoquer des erreurs cryptiques quand vous modifiez votre requête. Voici pourquoi vous devriez privilégier l’ordre par noms de colonnes, clair et robuste.
3 principaux points à retenir.
- Lisibilité: ORDER BY 1 est cryptique face à ORDER BY nom_colonne.
- Fiabilité: Modifier le select casse les requêtes avec positions ordinales.
- Maintenance: Changer l’ordre des colonnes dans SELECT modifie les résultats inopinément.
Pourquoi choisir ORDER BY avec noms plutôt qu’ordinales
Alors, pourquoi sur cette terre incroyable, devrions-nous préférer ORDER BY avec des noms de colonnes plutôt qu’avec ces fameuses positions ordinales, du genre ORDER BY 1, 2? Parce que c’est une pratique qui relève davantage de la sagesse que d’une simple option technique. Plutôt que de plonger dans un abîme d’incompréhensions et de surprises, choisir les noms de colonnes est non seulement plus fiable, mais cela rend également le code bien plus lisible.
Imaginez que vous travaillez sur une requête SQL un brin capricieuse. Vous faites un SELECT de multiples colonnes et, dans un moment d’inattention, vous décidez d’ajouter une colonne ou d’en modifier l’ordre. Puis, la terre s’écroule ! Votre ORDER BY 1, 2 n’a soudain plus aucun sens, comme un mail de votre boss à 18h30 un vendredi. Par contre, si vous aviez utilisé ORDER BY nom_colonne, la clarté serait au rendez-vous, et même les changements d’humeur des colonnes n’affecteraient pas la logique de tri. Vous éviteriez des erreurs inattendues dues à des modifications ultérieures.
Prenons un exemple simple. Supposons que vous ayez une requête :
SELECT nom, age, ville FROM utilisateurs ORDER BY 1;
Dans ce cas, « 1 » correspond à la colonne « nom ». Mais si quelqu’un décide d’ajouter une nouvelle colonne « email » au début ? Surprise ! Vous triez maintenant par « age » sans même le réaliser. En revanche, si vous aviez fait :
SELECT nom, age, ville FROM utilisateurs ORDER BY nom;Eh bien, cette fois, il n’y a pas de place pour la confusion. Vous êtes encrés dans votre vérité, et quoi qu’il arrive, votre requête reste cohérente.
À ce propos, en production, où la rigueur est une nécessité absolue, opter pour les noms de colonnes se transforme presque en mantra. Imaginez la tranquillité d’esprit que vous ressentirez lorsque, des mois plus tard, vous revisitez ce code. « Ah, oui, c’est bien ça ! » Pas de casse-tête, juste de l’ordre ! Un exemple tiré de la pratique illustre cela parfaitement : le monde du data engineering considère cette méthode comme un standard, et même des géants comme Microsoft en font l’éloge dans leur documentation ici.
En somme, privilégier les noms de colonnes dans votre ORDER BY est une décision qui s’inscrit dans une logique de durabilité, de clarté et de prévoyance. Comme on dit dans le milieu, mieux vaut prévenir que guérir… ou dans notre cas, mieux vaut triompher qu’être embarrassé par un tri illogique !
Quels risques réels cachent les positions ordinales en ORDER BY
Vous avez déjà entendu l’expression « ce qui se cache derrière les apparences » ? Eh bien, en SQL, il en va de même avec l’utilisation des positions ordinales dans l’instruction ORDER BY. Si vous êtes du genre à utiliser les positions ordinales sans réfléchir, préparez-vous à une sacrée dégringolade dans le monde des requêtes.
Imaginez cela : vous avez une requête que vous considérez comme parfaitement fonctionnelle, par exemple :
SELECT nom, age, ville FROM utilisateurs ORDER BY 1, 2;Ici, vous ordonnez vos résultats par nom et par âge. Parfait, n’est-ce pas ? Peut-être pas. Imaginez maintenant que, pour une raison obscure (comme le goût magnanime d’un développeur qui se prend pour Picasso), on décide d’ajouter une nouvelle colonne à la sélect, par exemple email :
SELECT nom, age, email, ville FROM utilisateurs ORDER BY 1, 2;Boom ! Les ordres ont changé ! Vous avez maintenant trié par nom et par email au lieu de nom et age. Si vous êtes chanceux, vous aurez seulement des résultats qui auront l’air étranges. Si vous êtes comme moi, préparé au mieux mais toujours pris par surprise, attendez-vous à découvrir des bugs qui surgissent comme des fantômes dans une pièce sombre de château.
Et ce n’est pas tout. Modifier l’ordre des colonnes peut également engendrer des conséquences insoupçonnées. Vous changez deux colonnes de place dans votre SELECT :
SELECT age, nom, ville FROM utilisateurs ORDER BY 1, 2;Là, vous vous retrouvez à trier par age puis par nom. Alors, direz-vous, ce n’est pas si dramatique ? Peut-être, mais dans un gros projet où vous avez des centaines de requêtes, des équipes et un nombre incalculable de clients, ces petites variations peuvent mener à du sabotage involontaire de la logique métier. On parlerait presque ici de la fourmi qui se traîne sur une autoroute, si elle est sur le bon chemin, super, mais si elle se retrouve au milieu des roues d’un camion…
Au final, ces positions ordinales, bien qu’elles puissent sembler séduisantes pour leur concision, sont en réalité des nids à problèmes, tant sur le plan fonctionnel qu’en matière d’entretien du code. Cela demande un effort supplémentaire pour maintenir la clarté et la cohérence de vos requêtes. Un coût en temps et en énergie qu’il serait peut-être plus sage d’éviter.
Quand et comment utiliser ORDER BY par positions ordinales sans risque
Ah, l’énigmatique commande ORDER BY et ses glorieux chiffres ! Quand il s’agit de trier vos données, certains d’entre nous n’hésitent pas une seconde à sortir le vieux ORDER BY 1, ORDER BY 2 comme s’ils commandaient un café au bar du coin. Cela peut sembler tentant, n’est-ce pas ? Surtout quand on est en mode « je fais ça rapido ». C’est un peu comme utiliser un raccourci : rapide, efficace, mais à quel prix ?
Dans certains cas, cette méthode peut se justifier. Imaginons que vous écriviez un petit script ad hoc pour explorer rapidement un jeu de données. Peut-être que vous êtes en train de réaliser une démonstration ou d’exécuter des requêtes temporaires que vous ne prévoyez pas de modifier prochainement. Dans ces situations, ORDER BY 1, 2 peut sembler inoffensif, voire même judicieux. Vous gagnez du temps, et ça marche.
- Conseil n°1 : documentez bien votre requête. Notez votre intention, expliquez votre logique. C’est un peu comme laisser une note d’amour à votre futur vous qui pourrait retrouver ce code dans trois mois.
- Conseil n°2 : évitez les modifications fréquentes. Si vous savez que ce code va changer tous les cinq jours, ne mettez pas la barre si haut, utilisez plutôt des alias explicites.
- Conseil n°3 : faites des revues de code rigoureuses. Si vous ne voulez pas qu’un collègue se retrouve avec un code incompréhensible, mettez-vous à deux pour éplucher ce qu’il y a dedans.
Et c’est là qu’intervient la solution intermédiaire : utilisez des alias explicites dans le SELECT. Par exemple, au lieu de dire ORDER BY 1, vous pouvez faire ORDER BY nom_colonne. Cela rend la requête à la fois concise et clair. Ne pas oublier que la lisibilité et l’entretien du code sont également essentiels !
Rappelez-vous bien, cependant, que dans un environnement de production, le ORDER BY par positions ordinales n’est pas quelque chose que vous devriez considérer comme une bonne pratique. Ne jouez pas au jeu du hasard avec vos données ; elles méritent mieux. Si vous voulez approfondir le sujet, jetez un œil à cette documentation qui pourrait vous éclairer davantage.
Alors, faut-il définitivement renoncer à ORDER BY par positions ordinales en SQL ?
Utiliser ORDER BY avec des positions ordinales est un raccourci trompeur, source d’erreurs sournoises et de code difficile à maintenir. La pratique expose vos requêtes à des bugs non détectés, notamment en production où la robustesse est cruciale. Optez pour un ORDER BY explicite avec les noms ou alias de colonnes : clairement plus lisible, plus sûr, plus professionnel. Vous gagnerez en fiabilité, en clarté et en temps de maintenance, ce qui vaut bien quelques frappes supplémentaires au clavier. Un petit investissement d’attention pour un gros retour en qualité.
FAQ
Pourquoi ORDER BY 1 est-il moins lisible ?
Quels problèmes entraîne l’usage d’ORDER BY avec des positions ordinales ?
Dans quels cas utiliser malgré tout ORDER BY 1, 2 ?
Comment sécuriser l’usage des positions ordinales dans ORDER BY ?
Pourquoi préférer les noms/alias en ORDER BY en production ?
A propos de l’auteur
Franck Scandolera, consultant indépendant et formateur depuis plus de dix ans, est expert en Web Analytics, Data Engineering et automatisation. À la tête de l’agence webAnalyste, il accompagne des professionnels dans la maîtrise du SQL, BigQuery et la structuration fiable des pipelines data, garantissant ainsi des analyses robustes et sans surprise. Passionné par la clarté du code et l’efficacité métier, Franck milite pour des pratiques rigoureuses et pérennes en data.
⭐ Expert et formateur en Tracking avancé, Analytics Engineering et Automatisation IA (n8n, Make) ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.