Utiliser ORDER BY avec des positions ordinales (ORDER BY 1, 2) rend votre SQL illisible et fragile. Ce raccourci casse vos requêtes si vous modifiez votre SELECT. Plongeons dans les raisons précises pour abandonner cette mauvaise habitude et écrire un SQL robuste.
3 principaux points à retenir.
- L’utilisation d’ordinal positions diminue la lisibilité du SQL.
- Modifier la sélection peut casser ou altérer l’ordre des résultats.
- Changer l’ordre des colonnes entraîne des résultats inattendus.
Qu’est-ce que l’ORDER BY avec positions ordinales en SQL
Alors, on se lance dans le vif du sujet : qu’est-ce que cette drôle d’idée d’utiliser des positions ordinales dans l’ORDER BY en SQL ? Vous savez, c’est cette méthode qui consiste à trier les résultats d’une requête en se basant sur des numéros de colonnes, comme dans un bon vieux classement à la loyale. Par exemple, vous pourriez écrire ORDER BY 1, 2. Cela signifie que vous voulez d’abord trier selon la première colonne de votre clause SELECT, puis selon la deuxième. Plutôt carré, non ?
Mais voilà le hic : derrière cette simplicité apparente se cache un sacré mal de tête potentiel. Techniquement, dans une requête SQL comme celle-ci :
SELECT nom, age, ville FROM utilisateurs ORDER BY 1, 2;l’ordinateur va se rappeler que 1 fait référence à nom et 2 à age. Mais imaginez que demain, vous rajoutiez une colonne sexe dans votre SELECT ! Panique à bord ! Vous devez impérativement vous souvenir de tous ces mouvements de colonnes. Ça devient du jonglage, et pas du cirque de bon niveau, je vous le garantis.
Pour bien saisir la différence, regardons un exemple avec les noms de colonnes, plus explicite :
SELECT nom, age, ville FROM utilisateurs ORDER BY nom, age;
Ah, voilà, c’est un peu plus clair, non ? Moins de risque de confusion, moins de méninges à échauffer. Si un jour vous devez modifier votre requête, il suffit de changer les noms des colonnes, pas de retracer les positions ordinales. Finalement, l’ORDER BY avec noms des colonnes est souvent l’approche la plus intuitive et moins sujette à l’erreur. En résumé, utiliser des positions ordinales, c’est un peu comme jouer à cache-cache avec soi-même dans la jungle des colonnes, alors qu’un bon vieux nom, c’est comme une pancarte au coin de la rue : ça aide sacrément à ne pas se perdre.
Quels sont les risques d’utiliser ORDER BY avec des positions ordinals
Utiliser les positions ordinales dans une clause ORDER BY, c’est un peu comme jouer à la roulette russe avec votre code. Pourquoi ? Parce que cette pratique peut générer des bugs difficiles à détecter. Imaginez un instant que vous avez écrit une requête SQL qui fonctionne comme un charme. Vous vous projetez déjà en train de faire des économies sur vos heures de debug, et puis, patatras ! Vous modifiez votre SELECT en ajoutant ou en supprimant des colonnes, et là, la requête précédente qui listait tout en ordre se transforme en une obscure bouillie.
Le problème majeur réside dans le manque de lisibilité. Quand vous écrivez ORDER BY 1, 2, vous faites référence à des colonnes par leur position. Cela semble pratique, mais où est la clarté ? Il est vite oublié que, si dans votre SELECT, la première colonne était nom, mais que vous avez ajouté âge avant, tout se désorganise. La première colonne est devenue âge, et maintenant, c’est ça que vous triez. Votre raisonnement basé sur les positions devient obsolète et remet en cause l’intégrité de votre requête.
Pour illustrer, prenons un exemple. Supposons que vous aviez cette requête initiale :
SELECT nom, prénom FROM utilisateurs ORDER BY 1, 2;
Jusque-là, tout fonctionnait. Mais voici qu’un collègue, plein de bonnes intentions, ajoute une colonne âge avant nom, tant qu’à faire, pour satisfaire un besoin pressant.
SELECT âge, nom, prénom FROM utilisateurs ORDER BY 1, 2;Boom ! Vous venez de trier par âge puis par nom. Si vous ne le savez pas, vous pourriez vous retrouver avec des résultats complètement illogiques. Cette situation est fréquemment la source d’erreurs en production, et croyez-moi, ça finit généralement dans le panier à problèmes des développeurs.
Les modifications de schéma, qui devraient normalement être une simple formalité, se transforment ici en un vrai casse-tête. En un claquement de doigts, votre requête, supposée efficace, devient une trappe à erreurs. Si vous voulez approfondir le sujet, je vous invite à jeter un œil à cet article qui contient des conseils pratiques pour éviter ce piège : ici. En gros, n’hésitez pas à être explicite : mentionnez toujours vos colonnes par leur nom. C’est une meilleure garantie pour la pérennité de votre code !
Comment écrire un ORDER BY efficace et durable
Quand il s’agit d’écrire vos requêtes SQL, la clarté et la robustesse passent avant tout. Favoriser les noms de colonnes explicites dans vos clauses ORDER BY ne fait pas que vous éviter des maux de tête : c’est la recette gagnante pour un code qui perdure. Alors, pourquoi se donner du mal, me direz-vous ? Parce qu’un code intelligible est un code qui évite les écueils.
Commençons par les bonnes pratiques d’écriture. D’abord, nommez clairement vos champs. Si vous avez une colonne qui contient des dates, appelez-la date_de_commande, pas d_comm. Ça fait classe, non ? Les abréviations obscures, c’est comme ces chemins de traverse dans une forêt : la plupart du temps, on se perd. Ensuite, si vous avez des clauses complexes, n’hésitez pas à les commenter. Un petit — Ceci trie les résultats par date croissante peut sauver une journée. Vos collègues (ou votre futur vous-même) vous en seront reconnaissants.
Attention, même si l’idée d’utiliser des positions ordinales peut allonger votre congé de frappe, ce gain de temps n’est pas un bon deal en environnement professionnel. Imaginez-vous trois mois plus tard, devant une requête que vous avez écrite avec la position 3 pour « nom » et 2 pour « date ». Quelle torture ! Ont-ils aussi inter-changé les colonnes ? À quel moment cela devient-il la recherche de la vérité dans une assiette de spaghetti ?
Pour illustrer ces principes, voici un exemple de requête bien structurée:
SELECT nom_client, date_commande, montant
FROM commandes
ORDER BY date_commande DESC, montant ASC;Dans cet exemple, c’est facile de comprendre ce qui se passe. On trie d’abord par date_commande dans l’ordre décroissant, puis par montant dans l’ordre croissant. Chaque champ a un nom explicite, et le raisonnement est clair comme de l’eau de roche.
En résumé, la prochaine fois que vous écrirez une requête SQL, rappelez-vous : jouez-la sécuritaire. Faites comme les grands chefs, qui ne mettent pas du sel à la place du sucre dans leurs recettes. Pour plus de conseils sur l’utilisation d’ORDER BY en SQL, je vous invite à consulter cet article intéressant ici.
Existe-t-il des cas où ORDER BY avec positions ordinales est acceptable ?
Alors, existe-t-il des cas où utiliser ORDER BY avec des positions ordinales en SQL peut être acceptable ? La réponse, en toute franchise, est oui. Mais ne vous emballez pas trop ; ce n’est pas la panacée. Dans des contextes très temporaires, exploratoires ou même lors de requêtes ad hoc, cette syntaxe peut être tolérée car, avouons-le, elle est rapide à écrire – un peu comme une descente de rivières en eaux vives où l’on file à toute allure et où l’on prend des raccourcis à outrance.
Cependant, et cela est crucial, en production, surtout lors de l’élaboration de pipelines ETL/ELT ou de rapports critiques, il est préférable de balayer cette pratique d’un revers de main. Les données, c’est sacré, et utiliser des positions ordinales, c’est comme naviguer sans boussole en mer agitée, vous risquez de vous échouer sur des récifs de désastre.
Comme l’écrit Tamas Ujhelyi dans son article sur les antipatterns SQL, « utiliser des positions ordinales peut mener à des requêtes fragiles et peu fiables ». Autant dire que ce n’est pas un cadeau qu’on veut offrir à ses collègues lorsqu’ils se penchent sur vos requêtes ! Les recommandations de fournisseurs comme PostgreSQL et BigQuery vont dans le même sens : bannissez cette pratique des environnements de production.
Mais il n’y a pas que des ombres dans ce tableau : il y a aussi des moments où l’utilisation de positions ordinales peut se faire sans trop de conséquences. Par exemple, si vous êtes en phase de prototypage et que vous testez rapidement différentes sorties sans se soucier d’un résultat « immédiatement fiable », alors OK, laissez-vous tenter. Toutefois, faites-le avec une dose de prudence ; gardez en tête que ce qui fonctionne en phase exploratoire peut s’avérer être un véritable casse-tête en production. Vérifiez toujours que la structure de votre requête, et donc l’ordre des colonnes, ne fluctue pas entre l’écriture et l’exécution du code.
En somme, un peu comme prendre un raccourci dans une ville inconnue, cela peut vous faire gagner du temps mais peut également vous perdre totalement. Alors utilisez ces positions ordinales avec discernement, et laissez-les de côté lorsque l’enjeu est la robustesse de vos données.
Alors, pourquoi persistons-nous encore avec ORDER BY 1, 2 ?
Utiliser ORDER BY avec des positions ordinales est un coup à vous faire perdre la tête et votre temps. Ce raccourci casse la lisibilité, engendre des bugs sournois lors des modifications, et rend votre code difficile à maintenir. En préférant les noms explicites, vous gagnez en clarté et en robustesse. À terme, cela vous évitera des down-times inutiles et des résultats aberrants. Écrire un SQL propre, c’est avant tout respecter les bonnes pratiques qui protègent vos données et votre activité.
FAQ
Pourquoi utiliser ORDER BY avec des noms de colonnes et non avec des positions ?
Quels problèmes peut causer ORDER BY 1, 2 en production ?
Y a-t-il des contextes où l’usage d’ordinal positions est toléré ?
Est-ce que tous les systèmes SQL supportent ORDER BY avec positions ?
Comment corriger une requête cassée à cause d’ORDER BY 1 ?
A propos de l’auteur
Je suis Franck Scandolera, consultant et formateur expert en Web Analytics, Data Engineering et SQL depuis plus d’une décennie. Responsable de l’agence webAnalyste, j’accompagne les professionnels dans la maîtrise de leurs données via des solutions techniques solides et durables. Maîtrisant BigQuery, SQL, et l’automatisation, je mets un point d’honneur à transmettre un savoir-faire pragmatique et précis, sans détour. Ma pédagogie vise à rendre vos requêtes fiables, lisibles, et adaptées à vos enjeux métiers réels.
⭐ 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.