Utiliser ORDER BY avec des positions ordinales en SQL rend vos requêtes fragiles, peu lisibles et sujettes aux erreurs. Lisez la suite pour comprendre pourquoi privilégier les noms de colonnes change votre manière d’écrire du SQL fiable et maintenable.
3 principaux points à retenir.
- ORDER BY avec positions ordinales est peu lisible et casse facilement
- Modifier la sélection impacte le résultat ou provoque des erreurs
- Privilégier les noms de colonnes renforce la robustesse et la clarté
Qu’est-ce que l’ordre par positions ordinales en SQL
Alors, qu’est-ce que l’ordre par positions ordinales en SQL, me direz-vous ? C’est tout simple : cela signifie utiliser des chiffres pour désigner les colonnes dans une clause ORDER BY. Par exemple, lorsque vous écrivez ORDER BY 1, 2, le chiffre 1 fait référence à la première colonne de votre requête, et le 2 à la deuxième. Une petite astuce qui, en théorie, devrait nous faire gagner du temps. Qui ne pourrait pas apprécier ça ?
Dans le domaine des bases de données, on utilise souvent l’ordre par positions ordinales pour des raisons pratiques. Les développeurs pensent à tort que cela rend leurs requêtes plus concises et plus rapides à écrire, surtout si vous avez la fâcheuse habitude de renommer vos colonnes avec des alias dans des requêtes complexes. “Regarde, je fais d’une pierre deux coups !” clamerait-on avec le sourire. Mais qu’en est-il vraiment ?
Voici une petite illustration pour vous donner une idée. Considérez cette requête simple :
SELECT nom, age FROM utilisateurs ORDER BY 1, 2;
Ce morceau de code va trier les utilisateurs, d’abord par leur nom, ensuite par leur âge. Facile, non ? Mais voyons une autre version, plus explicite :
SELECT nom, age FROM utilisateurs ORDER BY nom, age;Ici, au lieu de balancer des chiffres, vous utilisez les noms de colonnes directement. C’est plus clair, plus lisible, et surtout moins sujet à confusion. Imaginez que la structure de votre tableau change et que vous avez 20 colonnes. Si quelqu’un d’autre vient lire votre code, il risque de se perdre à essayer d’identifier ce que signifie ORDER BY 10. La beauté d’un bon code, c’est sa lisibilité !
Alors, la prochaine fois que vous pensez utiliser les positions ordinales pour faire le malin, réfléchissez à deux fois. Vous pourriez vouloir vous en tenir aux noms de colonnes pour garantir la clarté. Pour en savoir plus sur les enjeux de l’utilisation de ORDER BY, vous pouvez consulter cet article ici.
Quels sont les risques d’utiliser ORDER BY avec des positions ordinales
Utiliser des positions ordinales dans une clause ORDER BY en SQL, c’est un peu comme conduire une voiture avec les yeux bandés : vous pouvez avancer, mais il y a de fortes chances que ça dérape à un moment. En effet, cette pratique cache trois problèmes critiques : la lisibilité, la fragilité face aux modifications de colonnes dans le SELECT, et les résultats imprévus si l’ordre des colonnes change. Prenons le temps d’explorer chacun de ces problèmes avec des exemples concrets pour saisir le danger.
Premièrement, parlons de la lisibilité. Utiliser des positions ordinales peut rendre votre requête hermétique. Imaginez un développeur qui relit un code avec la clause suivante :
SELECT nom, age, salaire FROM employés ORDER BY 2;
Dans ce cas, quel est le tri ? Sur le âge ! Mais quelqu’un sans connaissance préalable va tourner les yeux en rond et, après quelques tentatives, se retrouver dans l’étrange paradoxie de déduire des « âges » à partir des « salaire ». De quoi provoquer quelques crises existentielles.
Ensuite, la fragilité de ce système pointe le bout de son nez. Imaginons maintenant que le tableau des colonnes subisse un petit lifting. Si notre SELECT évolue et que l’ordre change, la requête file un coup de vieux avec un simple coup d’œil :
SELECT nom, salaire, age FROM employés ORDER BY 2;Oh surprise ! Cette fois, c’est sur le salaire qu’elle trie. Certes, ce n’est généralement pas une catastrophe, mais dans des projets professionnels, chaque détail compte, et encore plus dans des pipelines de données ou sur des dashboards critiques.
Enfin, pourquoi se frotter à des résultats imprévus ? Imaginez un jour où un collègue a l’idée farfelue (ou pas) d’ajouter une colonne dans le SELECT. Le même code se transforme alors en un véritable casse-tête. Cette situation illustre à quel point les enjeux sont lourds : dans un projet d’envergure, ça peut vite devenir un cauchemar opérationnel ! La confiance dans les données s’évanouit, et croyez-moi, personne n’a envie de jouer les chasseurs de bogues dans une relation client.
Pour ces raisons, éviter les positions ordinales dans vos requêtes SQL devient une question de bon sens. Vous souhaitez en savoir plus sur ce sujet délicat ? Découvrez cet article.
Pourquoi préférer l’ordre par noms de colonnes en SQL
Utiliser les noms de colonnes dans la clause ORDER BY plutôt que des positions ordinales, c’est un peu comme choisir une carte au trésor au lieu de suivre un chemin tracé à la craie. La première option vous permet de savoir exactement où vous allez, tandis que la seconde peut très rapidement vous faire dérailler dans la tourmente des modifications de votre requête SQL. Mais pourquoi cette distinction est-elle si cruciale ?
Lorsque vous utilisez un numéro de colonne dans ORDER BY, vous pariez sur la structure de votre requête actuelle. Une petite modification dans votre SELECT, et paf ! Le numéro d’ordre peut ne plus correspondre à ce que vous aviez initialement en tête. Un vrai casse-tête ! Imaginez que votre requête de départ soit un chef-d’œuvre et qu’un numéro de colonne mal placé transforme ce chef-d’œuvre en charabia incompréhensible. En revanche, en utilisant le nom de la colonne, vous vous offrez une protection contre les changements inattendus. Si la colonne nom était à la position 2 aujourd’hui, elle le sera toujours tant que son nom reste le même. Pratique, non ?
Pour ajouter un peu de couleur à ces considérations, voici un tableau comparatif qui illustre clairement l’avantage de la méthodologie basée sur les noms de colonnes :
| Critères | ORDER BY Ordinals | ORDER BY Noms de Colonnes |
|---|---|---|
| Lisibilité | Difficile à comprendre, nécessite des repères | Immédiat, chaque colonne est identifiable |
| Maintenance | Risques d’erreurs élevés en cas de modification | Modifications sûres et souples |
| Erreurs potentielles | Peut causer des résultats imprévus | Résultats toujours cohérents |
Ne soyons pas timides et avouons-le, l’utilisation des noms de colonnes vous parle directement. Imaginez que vous soyez un chef cuisinier. Utiliser des noms de plats permet de vous assurer que chaque convive soit correctement servi, plutôt que de balancer un numéro dans une commande, risquant de rendre la bouffe délicieuse mais mal servie.
D’ailleurs, si cela vous tente d’approfondir encore plus votre compréhension des subtilités de ORDER BY, n’hésitez pas à consulter cet article passionnant. Vous verrez qu’une simple attention à la lisibilité peut véritablement transformer votre rapport au SQL. Qui aurait cru qu’un petit changement pourrait avoir un impact aussi colossal ? Allez, jouons franc jeu : les noms de colonnes sont définitivement votre meilleur ami pour maintenir l’harmonie de vos données.
Dans quels cas peut-on encore utiliser ORDER BY avec positions ordinales
Admettons-le, il y a des situations où l’utilisation de ORDER BY 1, 2 devient presque séduisante. Imaginez-vous en train de réaliser des requêtes ad hoc, un peu comme un chef cuisinier improvisant un plat avec les ingrédients du frigo – rapide, efficace, et parfois on ne s’attend pas à tant de saveurs. Dans des contextes d’exploration rapide de données, cette technique peut paraître tolérable, voire pratique. Vous avez des rapports à fournir dans l’urgence et vous n’avez pas le temps de vous familiariser avec les noms des colonnes ? Vous vous précipitez alors vers ces positions ordinales magiques, comme un cavalier de rodeo qui utilise les rênes d’une manière peu académique. Mais attention, cet élan d’audace, dans le code industriel ou dans des pipelines de production, doit être sérieusement reconsidéré.
Pourquoi tant de prudence ? Tout simplement parce qu’une fois que vous mettez les mains dans le cambouis d’un environnement de production, la clarté et la maintenabilité de votre code doivent passer au premier plan. Les chiffres, c’est séduisant, mais c’est aussi la voie royale vers la confusion. Imaginez le jour où un nouvel analyste de données se penche sur vos requêtes — interroger les colonnes selon leur position dans le SELECT, plutôt que selon leur nom, c’est comme prendre un raccourci tout en sachant qu’il comporte une déviation démesurée.
De nombreux experts, comme Balazs de ga4bigquery, reconnaissent que les positions ordinales peuvent être d’une certaine utilité, mais ils mettent en garde quant à leur utilisation en production. Dans un contexte robuste, où les données sont manipulées avec soin, il est impératif de garder chaque ligne de code lisible et compréhensible. Cela permet non seulement d’éviter des bugs potentiels, mais également d’assurer que le code pourra être maintenu sur le long terme.
Alors, pour tous les audacieux qui continuent à jeter un œil aux positions ordinales, réfléchissez à deux fois. La facilité apparente peut vous induire en erreur, et une fois que votre projet est en production, il n’y a rien de plus éprouvant que de tenter de démêler une erreur causée par une simple mais traîtresse ORDER BY 2. Vous voulez éviter les pièges ? Prenez un peu de temps pour écrire un code clair et maintenable, c’est l’assurance d’éviter bien des maux de tête à l’avenir. En somme, les positions ordinales, c’est bien, mais uniquement pour vos petites escapades, pas pour la grande aventure de la production.
Pour une plongée plus approfondie sur les dangers des numéros ordinaux dans SQL, n’hésitez pas à consulter cet article éclairant sur les anti-patterns SQL.
Faut-il abandonner vraiment ORDER BY 1, 2 en SQL ?
L’utilisation d’ORDER BY avec positions ordinales est une mauvaise habitude qui peut coûter cher. Peu lisible, fragile face aux évolutions du code SQL, elle expose à des erreurs subtiles de résultats. Privilégier les noms de colonnes dans ORDER BY est une garantie simple pour un code clair, maintenable et stable. Pour tout projet sérieux en data ou reporting, ne cédez pas à la facilité artificielle du gain de frappe. Vous gagnerez en fiabilité et pérennité, deux qualités bien plus précieuses que quelques caractères économisés.
FAQ
Pourquoi utiliser ORDER BY avec positions ordinales ?
Quels sont les risques d’ORDER BY avec positions ordinales ?
Comment améliorer la lisibilité de ORDER BY ?
Quand peut-on tolérer ORDER BY avec positions ordinales ?
Y a-t-il une recommandation officielle à ce sujet ?
A propos de l’auteur
Franck Scandolera, analyste senior et consultant indépendant, cumule plus de dix ans d’expérience en analytics, data engineering et automatisation. Avec une spécialisation en SQL, BigQuery et pipelines data, il accompagne agences et entreprises sur des projets exigeants et forme des professionnels à écrire un code clair, puissant et robuste, centré sur la qualité et la conformité.
⭐ 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.