Utiliser ORDER BY avec des positions ordinales (1, 2…) plutôt que des noms de colonnes complexifie vos requêtes et peut causer des erreurs sournoises. Découvrez pourquoi ce réflexe SQL est à proscrire pour assurer clarté et robustesse dans vos scripts.
3 principaux points à retenir.
- Lisibilité : ORDER BY 1 est ambigu, ORDER BY nom_colonne est clair.
- Maintenance : Modifier la liste SELECT casse l’ordre si vous utilisez des positions.
- Risques : Changements dans l’ordre des colonnes faussent les résultats.
Qu’est-ce que ORDER BY avec positions ordinales en SQL
Tu sais ce que c’est SQL, n’est-ce pas ? Ce langage qui te permet de jongler avec des bases de données comme un prestidigitateur avec des cartes ? Donc, parlons d’une petite astuce qui pourrait te tourner en bourrique si tu n’y fais pas attention : l’utilisation de ORDER BY avec des positions ordinales, autrement dit, ORDER BY 1, 2.
Quand on dit ORDER BY 1, 2, on fait référence aux colonnes de la liste SELECT selon leur position. Oui, tu as bien entendu ! Si tu as, par exemple, une requête qui ressemble à ça :
SELECT nom, age FROM utilisateurs ORDER BY 1, 2;Eh bien, le 1 correspond à la colonne nom et le 2 au age. Tranquille, non ? En théorie, ça te fait gagner du temps en écrivant moins. Mais comme toujours, le diable est dans les détails. Imagine que quelqu’un vienne à modifier la requête en ajoutant une nouvelle colonne, disons ville. Maintenant, ta requête ORDER BY 1, 2 va commander les résultats non pas par nom puis âge, mais par nom et ensuite, bingo, par ville, car 1 et 2 ne sont plus « fixes ». Ça devient le bazar !
Et, alors, qui utilise cette syntaxe peu recommandable ? Eh bien, plusieurs systèmes de gestion de bases de données (SGBD) comme MySQL, PostgreSQL et Oracle la supportent. Mais si l’on y regarde de plus près, elle présente des limitations. Par exemple, elle ne permet pas de comprendre directement quelles colonnes sont utilisées pour trier les résultats sans revoir 100% de la requête. Et comment veux-tu déboguer ça si un jour ça ne fonctionne pas comme prévu ? C’est un peu comme conduire sans voir le tableau de bord : dangereux !
En somme, si tu veux éviter d’être le clown de la revue de code, n’hésite pas à utiliser les noms de colonnes explicites dans tes clauses ORDER BY. C’est lisible, clair et ça évite les surprises. Si tu veux approfondir cette question insolite, je te laisse le lien suivant pour explorer les anti-patterns de SQL : lire ici.
Quels sont les risques réels d’utiliser ORDER BY 1, 2
Utiliser ORDER BY 1, 2 dans vos requêtes SQL, c’est un peu comme vous engager dans un rendez-vous à l’aveugle : vous pourriez finir par draguer la mauvaise colonne ! Passons en revue les risques réels de cette pratique insidieuse.
- Baisse de lisibilité : Quand vous tapez
ORDER BY 1, 2, vous avez affaire à une obscurité volontaire. Imaginez un novice qui ouvre votre code. Il le lit et se dit : « Super, je veux trier par les colonnes 1 et 2… » Mais qu’est-ce que c’est, ces colonnes ? Doit-il retourner auSELECTinitial pour vérifier leurs noms ? Un véritable casse-tête. Plus vous rendez votre code illisible, plus vous risquez d’attraper une migraine à chaque modification. - Rupture facile lors d’ajout ou de suppression de colonnes : Vous avez décidé d’ajouter une nouvelle colonne à votre
SELECT? Prends garde, pauvre âme ! Si la colonne 2 est supprimée ou devenue votre colonne 3, alors votre tri devient complètement fou. Imaginez, toutes ces données perturbées par vos changements. Au final, le mauvais tri ne fait pas que causer de la confusion ; il pourrait également fausser les rapports analytiques. - Erreurs sournoises : Et là, c’est le drame. Si vous modifiez l’ordre des colonnes dans votre
SELECTsans ajuster l’ORDER BY, vous venez de créer un cocktail explosif de désinformation. Un petit changement dans l’ordre, et boum ! Vos résultats sont plus erronés qu’une prédiction météo de juillet. Ces erreurs, souvent invisibles, peuvent persister dans votre base de données, vous laissant dans l’obscurité. C’est comme retourner à un vieux film où le héros se fait piéger parce qu’il n’a pas vérifié son environnement.
Pour illustrer cela, prenons l’exemple d’une table de ventes. Si vous avez SELECT id, produit, prix et que vous utilisez ORDER BY 1, 2, votre tri se fait par id puis produit. Imaginez que vous ajoutiez une colonne date et que vous décidiez de retirer produit. Votre ORDER BY ne changera pas. Cela pourrait vous donner le tri de vos ventes par id et maintenant par date sans que vous ne le sachiez. La mauvaise surprise, n’est-ce pas ?
Alors oui, utilisez la numérotation des colonnes à vos risques et périls. Vous n’avez pas envie de vivre le cauchemar d’un tri infernal, n’est-ce pas ? Si vous ne me croyez pas, jetez un œil à cette discussion sur StackOverflow. Vous y trouverez des témoignages de développeurs qui ont fait face aux conséquences de cette décision malavisée. Choisissez toujours la clarté, car le flou, c’est pour les souffrances !
Pourquoi privilégier les noms de colonnes en ORDER BY
Utiliser ORDER BY 1, 2 en SQL, c’est un peu comme mettre des œillères et prétendre que le monde est à l’endroit. D’un côté, ça semble pratique : qui n’a jamais voulu trier une requête sans avoir à se souvenir des noms de colonnes à chaque fois ? Mais en réalité, cette approche cache une multitude de problèmes. Alors, pourquoi privilégier les noms explicites des colonnes dans ORDER BY ?
Premièrement, l’utilisation de noms de colonnes garantit la robustesse de votre code. Imaginez que vous travaillez en équipe ou que vous revenez sur un projet six mois plus tard. Vous ouvrez votre requête SQL pleine de ORDER BY 1, 2. Vous avez une soudaine révélation : que représentent ces « 1 » et « 2 » ? Un véritable casse-tête ! En revanche, si vous avez choisi les noms de colonnes, comme ORDER BY nom, age, tout est clair et accessible. Vos collègues, ainsi que votre futur vous, vous en remercieront.
Ensuite, ça devient encore plus intéressant quand on évoque la maintenance. Les bases de données évoluent, les colonnes peuvent être ajoutées, supprimées ou renommées. En utilisant des index numériques, vous vous exposez à des erreurs de tri si votre SELECT subit des modifications. Voici un exemple typique :
-- Mauvaise pratique
SELECT nom, age, ville
FROM utilisateurs
ORDER BY 1, 2;
-- Bonne pratique
SELECT nom, age, ville
FROM utilisateurs
ORDER BY nom, age;
Dans le premier cas, si vous décidez d’ajouter une nouvelle colonne, par exemple email, l’ordre de tri reste incertain. Alors qu’avec l’approche « nom explicite », l’intégrité de votre code est préservée et il est facile de lire d’un coup d’œil l’intention de votre requête.
Enfin, parlons de clarté. En utilisant des noms de colonnes, vous améliorez la lisibilité pour ceux qui relisent le code, ce qui est une pratique non seulement appréciée, mais essentielle dans le travail collaboratif. Comme l’a dit le célèbre informaticien Martin Fowler : « Les noms des choses se figent dans le temps, tandis que les détails d’implémentation doivent évoluer. »
Alors, la prochaine fois que vous écrivez une requête SQL, posez-vous cette question : voulez-vous que votre code ressemble à un labyrinthe ou à une route bien balisée ? Optez pour les noms de colonnes et assurez-vous que votre code soit aussi clair qu’un jour ensoleillé. Pour plus d’infos sur le sujet, pourquoi ne pas visiter ce lien ?
Quand et pourquoi certaines personnes utilisent-elles ORDER BY avec des positions
Alors, qu’est-ce qui pousse certains développeurs à tomber dans le piège de l’ORDER BY 1, 2 ? Ça semble tentant, n’est-ce pas ? Gagner quelques frappes clavier, être plus rapide dans des scripts exploratoires, un vrai petit coup de pouce qu’on s’offre. Balazs, un éditeur reconnu, avoue dans un article qu’il utilise cette syntaxe pour sa commodité tout en reconnaissant les limites de cet abord. Si même des pros comme lui passent parfois à côté de l’essentiel, c’est qu’il doit bien y avoir un fond de vérité !
La logique derrière cette méthode s’ancre dans un besoin de rapidité : on évite de taper les noms des colonnes, surtout quand on travaille sur des requêtes ad hoc, où le stress est présent et le temps compté. Imaginez : un projet urgent, des données à trier, et hop, un petit ORDER BY 1, 2 et le tour est joué. Pratique, non ? Sauf que… Oui, il y a un énorme « mais » !
- Lisibilité : C’est l’éléphant dans la pièce. Qui, à part vous, saura ce que signifient ces chiffres ? Vous, un beau matin, en train de relire votre chef-d’œuvre, et là, stupeur, vous vous demandez : « C’est quoi déjà cette colonne ? » La lisibilité est sacrifiée sur l’autel de la rapidité !
- Maintenance : Admettons qu’un collègue prenne votre code un peu ancien (et sûrement poussiéreux). S’il voit du
ORDER BY 1, 2, il passera des heures à comprendre votre intention. Ça revient à laisser un labyrinthe sans sortie ! - Erreurs silencieuses : Quand vos données changent, les colonnes, elles, peuvent bouger aussi. Un beau jour, vous pourriez vous retrouver à trier sur les mauvaises colonnes. Oui, exactement, cela arrive bien plus vite que prévu !
Alors, peut-on dire que cette pratique est justifiée ? Peut-être dans des contextes informels, mais dans une production sérieuse et industrialisée, c’est un coup de poker qu’il vaut mieux éviter. On est là pour produire du code robuste, pas pour jouer aux devinettes. Pour se former à une utilisation plus professionnelle et réfléchie des commandes SQL, jetez un œil dans des ressources comme celles-ci qui apportent de la clarté à vos ordres SQL.
Comment écrire des requêtes SQL robustes et éviter les pièges d’ORDER BY
Pour qu’une requête SQL soit robuste et fiable, il est impératif d’éviter les pièges que l’on pourrait rencontrer lors de l’utilisation de ORDER BY 1, 2. Mais alors, comment s’y prendre pour écrire des requêtes qui ne vous laisseront pas en plan lors d’un audit ou, pire, devant un client ? Voici quelques conseils pratiques.
- Privilégiez des noms explicites : Plutôt que d’utiliser les positions des colonnes, mentionnez toujours le nom de la colonne dans votre clause
ORDER BY. Clairement, cela facilite la lecture pour quiconque lit votre code, même pour le vous du lendemain qui pourrait ne pas se souvenir des colonnes par leur position. - Documentez vos requêtes complexes : Laissez des commentaires dans votre code. Expliquez pourquoi vous ordonnez par cette colonne précise. Une bonne documentation peut faire la différence entre un développeur qui patauge et un autre qui se livre à une promenade de santé dans les données.
- Testez les impacts des modifications : Lorsque vous modifiez l’ordre des colonnes dans votre requête, testez les résultats pour vérifier que l’ordre est toujours celui que vous espériez. Un petit test peut vous éviter de grands maux de tête !
Pour mieux comprendre les enjeux, j’ai concocté un tableau comparatif qui fait le tour d’horizon des avantages et inconvénients entre ORDER BY avec positions et noms de colonnes :
| Critères | ORDER BY Position | ORDER BY Nom de Colonne |
|---|---|---|
| Lisibilité | ⬇️ Difficile à comprendre | ⬆️ Très clair |
| Adaptabilité | ⬇️ Risque d’erreur si structure change | ⬆️ Flexible même si la structure évolue |
| Performance | ⬆️ Potentiellement plus rapide | ⬆️ Légèrement plus lent, mais négligeable sur petit volume |
Voici un exemple de requête SQL fiable que vous pourriez utiliser dans BigQuery, intégrant ces bonnes pratiques :
SELECT nom, age, ville
FROM utilisateurs
ORDER BY nom, age
Cette requête est non seulement claire, mais elle est également extensible, vous permettant de modifier l’ordre sans vous soucier des positions de colonnes. Adoptez ces bonnes pratiques et regardez vos requêtes devenir un modèle de clarté et d’efficacité ! Pour plus de détails sur les ordres de colonnes, n’hésitez pas à consulter cet article ici.
Alors, pourquoi continuer à utiliser ORDER BY 1,2 quand on peut faire mieux ?
L’utilisation d’ORDER BY avec des positions ordinales est un piège courant qui peut transformer vos requêtes SQL en véritables bombes à retardement. Peu lisible et fragile, ce réflexe vous expose à des erreurs sournoises dès qu’on modifie la structure des colonnes. Adopter les noms explicites dans ORDER BY, c’est assurer la clarté, la maintenabilité et la robustesse de votre code. Vu l’économie minime en frappes, ce choix est un non-sens pour des scripts destinés à durer ou être partagés. En bref, évitez le shorthand dangereux pour un SQL plus responsable et maîtrisé.
FAQ
Pourquoi ORDER BY 1, 2 est-il déconseillé ?
L’usage d’ORDER BY avec noms est-il universellement compatible ?
Y a-t-il un contexte où ORDER BY 1, 2 peut être utile ?
Comment éviter les erreurs liées à ORDER BY dans mes requêtes ?
Cette règle s’applique-t-elle uniquement à BigQuery ?
A propos de l’auteur
Franck Scandolera, expert en analytics et ingénierie data, accompagne depuis plus d’une décennie les entreprises dans la structuration, l’automatisation et l’optimisation de leurs dispositifs data. Responsable de l’agence webAnalyste et formateur reconnu sur BigQuery et SQL, il maîtrise en profondeur les bonnes pratiques pour rendre vos requêtes non seulement fonctionnelles mais durables dans le temps. Avec une expertise technique et pédagogique, il s’assure que vos pipelines ne deviennent jamais des usines à bugs, mais de véritables leviers business fiables.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GTM server, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, 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.