ORDER BY 1, 2 en SQL semble pratique mais introduit erreurs et incompréhensions. Utilisez plutôt les noms de colonnes pour éviter des bugs sournois liés aux modifications du SELECT selon Tamas Ujhelyi, expert BigQuery.
3 principaux points à retenir.
- ORDER BY 1, 2 est moins lisible, les noms de colonnes parlent d’eux-mêmes.
- Modifier la requête casse souvent le tri si on utilise des positions ordinales.
- Changer l’ordre des colonnes dans SELECT perturbe l’ordre attendu dans le résultat.
Qu’est-ce que l’ORDER BY avec positions ordinales en SQL
Quand on parle de ORDER BY dans une requête SQL, beaucoup de développeurs pensent, à tort ou à raison, que la version simplifiée, celle qui utilise des positions ordinales, est une astuce pour gagner du temps. En fait, ces chiffres ne sont rien de moins que des références à la position des colonnes dans la clause SELECT. Mais avant de se réjouir de cette prétendue simplification, il faut vraiment creuser.
Imaginez que vous avez une table contenant les informations des employés : nom, âge et salaire. Si vous exécutez une requête comme celle-ci :
SELECT nom, age, salaire FROM employes ORDER BY 1, 3;Dans ce cas, 1 fait référence à la première colonne, soit nom, et 3 à la troisième colonne, soit salaire. Résultat ? Vos employés sont triés par nom, puis, si deux employés partagent le même nom, triés par salaire. Pratique, non ?
Il est vrai que cette méthode peut sembler séduisante pour des requêtes rapides et des manipulations temporaires. Les développeurs en quête d’efficacité – ou pour être plus précis, les développeurs pressés – voient les positions ordinales comme un raccourci confortable. Pas besoin de taper les noms de colonnes, juste deux chiffres et le tour est joué. Mais là où ça devient dangereux, c’est lorsque le schéma de la base de données change. Supposons que vous décidiez d’ajouter une nouvelle colonne qui devient la nouvelle colonne 2. Votre requête, qui, au départ, semblait claire, se transforme alors en un vrai casse-tête. C’est l’effet Caméléon : d’un coup, elle ne correspond plus à vos attentes.
Certaines bonnes pratiques, comme nommer explicitement vos colonnes dans l’ORDER BY, permettent de prévenir ce genre de désastre. En fait, la documentation SQL et la communauté des développeurs s’accordent à dire qu’il est souvent préférable d’éviter cette approche. L’utilisation des noms de colonnes augmente la lisibilité et réduit les erreurs potentielles. Pourquoi ne pas faire ça etosez la tranquillité d’esprit ?
Pensez à une citation de Henri Bergson qui disait : « L’instinct, c’est la mémoire des choses que nous avons oubliées. » Ici, cela signifie que choisir des positions ordinales, c’est oublier l’importance du contexte. Si vous voulez en savoir plus sur les implications des ordres dans SQL, n’hésitez pas à consulter cet article (source StackOverflow).
Quels sont les risques d’utiliser ORDER BY avec des positions ordinales
Vous savez, utiliser ORDER BY avec des positions ordinales comme 1 ou 2 en SQL, c’est un peu comme jouer à la roulette russe : on ne sait jamais sur quel pied danser ! Oui, parce que derrière cette syntaxe énigmatique se cache un monde de risques qui devraient faire frémir même le développeur le plus aguerri.
La première menace ? La lisibilité du code. Quand on croise des chiffres au lieu de noms de colonnes, ça complique sacrément la vie. Imaginez-vous relisant ce code un lundi matin, avec le café qui coule encore. Vous tombez sur une requête telle que :
SELECT name, age, salary FROM employees ORDER BY 1, 2;
Alors, 1 et 2, c’est quoi ? Le nom ou l’âge ? L’oublier ou ne pas le savoir pourrait mener à des interprétations erronées et des bugs qui vous coûteraient plus cher qu’une tournée générale dans un bar à cocktails.
Et ça, ce n’est que la partie émergée de l’iceberg. Le véritable drame survient lorsque vous décidez de modifier votre SELECT. Imaginez que vous ajoutiez une colonne pour l’adresse :
SELECT name, age, address, salary FROM employees ORDER BY 1, 2;Oh surprise ! Vous pensez trier par nom et âge, mais en fait, vous commencez à trier par adresse et nom. Cela entraîne des résultats inattendus. Vous n’avez non seulement pas trié comme voulu, mais vous pourriez aussi avoir des confusions dans des rapports ou des analyses cruciales.
Et ce n’est pas fini ! Même si vous pensez qu’en gardant la même structure logicielle, rien ne bouleversera votre jolie petite commande, je vous le dis : l’ordre des colonnes dans le SELECT fait varier l’effet du ORDER BY ordinal. Résultat ? Une avalanche de bugs à quel prix ! Chaque ligne de code, chaque position, doit être calculée avec soin. Au lieu de faire dans l’inconnu, optez pour la clarté et l’intelligibilité. La simplicité est la sophistication suprême.
Pour plus de détails sur les pièges à éviter en SQL, je vous invite à fouiller cet article très complet que j’ai trouvé : SQL Antipatterns.
Comment éviter ces problèmes et meilleures pratiques
Pour naviguer habilement dans les méandres du langage SQL sans tomber dans le piège des positions ordinales, quelques bonnes pratiques s’imposent. La règle d’or? Utiliser les noms des colonnes dans l’instruction ORDER BY. Oui, je sais, cela semble évident, mais la simplicité des bonnes idées est souvent trompeuse. Imaginez-vous être devin pour comprendre une requête lue par un collègue, juste parce qu’il avait l’audace de dire à SQL « Triage, s’il te plaît, mais en utilisant le troisième enfant du classeur! » Non, merci !
En employant les noms des colonnes, on s’assure que nos requêtes restent stables, compréhensibles et surtout, maintenables. Prenez un exemple basique :
SELECT nom, age FROM utilisateurs
ORDER BY age;
Ce code est parfaitement limpide. Si, par ailleurs, vous aviez utilisé ORDER BY 2, imaginez les maux de tête lors de l’ajout de colonnes ultérieurement. Un changement de structure et paf! Votre requête devient un mystère. C’est comme s’inviter à un dîner et découvrir que le menu a changé depuis la seule fois où vous y êtes allé.
En plus de ça, utiliser les noms de colonne facilite aussi la collaboration au sein d’une équipe. Qui ici n’a jamais passé des heures à déchiffrer une logique absente juste parce qu’un dénommé « 453 » était en train de semer le trouble, alias ce fameux numéro de colonne? Avec les noms, chacun sait exactement de quoi il retourne.
Pour illustrer les différences entre ces méthodes, voici un petit tableau comparatif :
| Méthode | Exemple | Risques |
|---|---|---|
| Par position | ORDER BY 2 | Changement de structure = erreur potentielle |
| Par nom | ORDER BY age | Aucun, c’est stable! |
En somme, le bon sens crie à chaque développeur de préférer la clarté au mystère. Croyez-moi, une convention simple aujourd’hui vous évitera des tracas demain. Pour en découvrir davantage sur la magie de ORDER BY, n’hésitez pas à jeter un œil à cet article qui pourrait bien vous éclairer encore plus. Le mauvais usage des positions ordinales, c’est un peu comme saboter son propre gâteau d’anniversaire. Alors, adoptez les bonnes habitudes, et croquez la vie à pleines dents !
Faut-il bannir les positions ordinales dans ORDER BY en SQL ?
L’utilisation d’ORDER BY avec des positions ordinales peut sembler astucieuse au premier abord mais elle se révèle rapidement source de confusion, d’erreurs et de maintenance difficile. Privilégier l’ordre par nom de colonne améliore nettement la lisibilité et la robustesse des requêtes, essentiel dans les environnements professionnels. Vous évitez ainsi des bugs subtils liés à la modification des requêtes, ce qui vous fait gagner du temps et sécurise votre travail. En clair, abandonnez ORDER BY 1, 2 pour un SQL plus net, plus fiable et professionnel.
FAQ
Qu’est-ce que ORDER BY 1 en SQL ?
Pourquoi éviter ORDER BY avec des positions ordinales ?
ORDER BY avec noms de colonnes est-il toujours préférable ?
Existe-t-il des cas où ORDER BY 1 peut être utile ?
Quels outils aident à éviter ce genre d’erreurs en SQL ?
A propos de l’auteur
Franck Scandolera est consultant et formateur expert en Web Analytics, Data Engineering et SQL depuis plus de 10 ans. Responsable de l’agence webAnalyste, il pilote des infrastructures data complexes et forme régulièrement agences et entreprises à BigQuery et à l’optimisation des requêtes SQL. Son expérience terrain lui permet de délivrer des conseils pratiques et robustes évitant les pièges classiques du SQL dans le monde professionnel.
⭐ 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.