ORDER BY 1,2 en SQL trie selon la position des colonnes, mais c’est une mauvaise idée : code illisible, résultats instables, casse facile. Voici pourquoi il faut privilégier l’ordre par nom de colonne, bien plus robuste et clair.
3 principaux points à retenir.
- Lisibilité : Ordre par nom de colonne facilite la compréhension immédiate du tri.
- Robustesse : Ajouter ou réordonner des colonnes ne casse pas la requête.
- Maintenance : Moins d’erreurs imprévues quand la structure évolue.
Qu’est-ce que ORDER BY avec positions ordinales en SQL
ORDER BY 1,2, c’est un classique du tri à la sauce SQL. Pour ceux qui ne sont pas familiers, c’est tout simplement une manière de trier vos résultats selon les positions des colonnes sélectionnées, plutôt que d’utiliser leurs noms explicites. En d’autres termes, ça veut dire que si vous avez une requête qui sélectionne les colonnes A, B, et C, ORDER BY 1,2 va trier vos résultats par la première colonne (A), puis par la deuxième (B). Simple, non ?
Imaginez un petit exemple pour mieux visualiser. Supposons que vous ayez une table clients avec les colonnes nom, age, et ville. Voici le code SQL :
SELECT nom, age, ville FROM clients ORDER BY 1, 2;Ce code triera les clients d’abord par nom, puis par age. On le comprend bien, mais pourquoi certains développeurs optent-ils pour ORDER BY 1,2 ? La réponse est souvent : la fainéantise. On cherche à gagner du temps et à taper moins. Sauf que comme c’est souvent le cas avec l’automatisation, ces petites économies de frappe peuvent avoir des conséquences fâcheuses.
Par exemple, si la structure de la table change, que vous ajoutez une nouvelle colonne, et que vous ne l’insérez pas dans votre requête, vos résultats peuvent devenir complètement illogiques. Utiliser ORDER BY 1,2 change alors illico tout votre jeu de tri sans que vous ne vous en rendiez compte. Il est facile de se retrouver dans une situation où l’on croit trié par la bonne colonne mais en fait on triait par la mauvaise. La clarté est tout !
À la place, opter pour les noms des colonnes est souvent plus judicieux. Voici la même requête, mais plus explicite :
SELECT nom, age, ville FROM clients ORDER BY nom, age;En clair, même si votre passion pour le raccourci vous appelle, mieux vaut parfois y réfléchir à deux fois. La lisibilité et la pérennité de votre code en dépendent. N’oubliez pas, comme le disait Socrate : « Le secret du changement consiste à concentrer toute votre énergie, non pas à lutter contre l’ancien, mais à construire le nouveau. » Alors, pourquoi ne pas construire du code qui respire la clarté ?
Quels sont les risques d’utiliser ORDER BY 1,2 dans mes requêtes
Utiliser ORDER BY 1,2 dans vos requêtes SQL, c’est un peu comme emballer des biscuits dans du papier journal pour une réception. Ça peut faire le job, mais ça n’est pas vraiment élégant et surtout, ça expose à des risques. Commençons par le plus évident : la lisibilité. Quand vous recourez à cette technique, vous demandez à vos lecteurs (et à vous-même, en particulier dans six mois quand vous serez à la recherche de ce code bien caché) de deviner ce que signifient ces chiffres. C’est comme faire un bon vieux casse-tête sans image pour s’aider. La prochaine fois que vous tomberez sur votre requête, vous vous demanderez probablement : « Mais que représentent ces 1 et 2 ? ». Frustrant, non ?
Et puis, imaginez que vous ajoutiez une colonne dans votre sélection. Vous avez beau être un ninja en SQL, cette modification totalement innocente peut transformer l’ordre de tri en un joli plat de spaghettis en désordre. Par exemple, prenons une requête qui trie par ORDER BY 1, c’est-à-dire par la première colonne sélectionnée, imaginons qu’elle soit nom. Vous avez donc :
SELECT nom, age FROM utilisateurs ORDER BY 1;Après, vous décidez d’ajouter une colonne pour afficher le prénom :
SELECT prénom, nom, age FROM utilisateurs ORDER BY 1;Dans ce nouveau cas, c’est finalement par prénom que vous triez, et plus par nom. Ce changement totalement involontaire peut mener à des résultats que vous n’aviez pas anticipés, et surtout, à des erreurs dans des applications qui dépendent de cet ordre particulier. Qui a dit que les bases de données étaient faciles ?
Enfin, tout variation dans votre structure de colonnes peut entraîner des résultats totalement différents. Pas très fiable tout ça, n’est-ce pas ? Alors, répétons-le : ORDER BY 1,2 peut vous faire perdre le contrôle. C’est un peu comme jouer à la roulette avec vos données. Voici un tableau synthétique qui récapitule les risques et les avantages :
| Critère | Risques | Avantages |
|---|---|---|
| Lisibilité | Pauvre, nécessite de deviner | Rapide à écrire |
| Stabilité | Sensibilité aux changements de colonnes | Aucun |
| Maintenance | Facile à casser | Peut sembler plus concis |
Comment rendre mes requêtes plus robustes sans ORDER BY 1,2
Ah, le tant redouté ORDER BY 1,2 ! Vous savez, ce petit tour de magie qui peut sembler séduisant au premier coup d’œil, mais qui, à la longue, s’avère être un véritable casse-tête. Oui, parce qu’en SQL, la clarté et la lisibilité sont tout sauf accessoires. Si vous ne voulez pas terminer dans le livre des regrets de la programmation, il est grand temps d’adopter des pratiques qui rendent vos requêtes plus robustes.
Commençons par la base : au lieu de recourir à cet obscure ORDER BY 1,2, misez sur des tris explicites. Qu’est-ce que cela veut dire ? Simplement que vous devez remplacer ces obscurs numéros par les noms des colonnes réelles. Pourquoi ? Tout simplement parce qu’un tri explicite est bien plus lisible et permet d’éviter des erreurs sournoises au sein de vos pipelines de production. Imaginez-vous faire un petit brushing à vos données, puis, dans un moment d’égarement, modifier la requête sans penser à mettre à jour les ordres de tri. Paf ! Vous renvoyez vos résultats triés par des colonnes que vous n’aviez même pas l’intention d’utiliser. On préférerait éviter ce scénario digne d’un film d’horreur, n’est-ce pas ?
Pour clarifier les choses, prenons un exemple concret. Supposons que vous avez la requête suivante :
SELECT nom, age, ville FROM utilisateurs ORDER BY 1, 2;Si l’on la transforme, cela donne :
SELECT nom, age, ville FROM utilisateurs ORDER BY nom, age;Voilà ! C’est beaucoup plus clair, non ? En plus, si à un moment donné vous désirez ne trier que par nom, il vous suffit d’enlever age sans perdre de temps à vérifier quel numéro correspond à quoi. La maintenance devient un vrai jeu d’enfant.
En gros, en optant pour des ordres de tri explicites, vous assurez la robustesse de vos requêtes. C’est un investissement sur le long terme qui vous épargnera des tracas futurs. Alors faites le choix de la lisibilité et faites briller vos compétences en SQL ! Au fait, pour ceux qui veulent approfondir, vous pouvez jeter un œil à cette source.
Pourquoi certains utilisent encore ORDER BY 1,2 malgré les risques
Vous vous demandez pourquoi certains développeurs persistent encore à utiliser ORDER BY 1,2 ? Laissez-moi vous donner quelques pistes d’explication. D’abord, il y a un certain charme à la simplicité : qui ne serait pas tenté d’écrire quelques chiffres pour trier ses données, au lieu de galérer avec des noms de colonnes parfois longs comme un roman de Victor Hugo ? C’est rapide, ça fait classe, et avouons-le, ça peut donner une impression de compétence. Ce raccourci est tentant et, pour beaucoup, une habitude bien ancrée. C’est un peu comme sortir le vieux tournevis encore rouillé pour visser quelque chose en lieu et place d’un outil adapté. Ça fonctionne… jusqu’à un certain point.
Les environnements SQL, comme SQL Server Management Studio ou certains outils de BI, n’émettent souvent aucun avertissement lorsque vous utilisez ce style de tri. Bonjour l’illusion de sécurité ! Certains développeurs, en particulier ceux qui naviguent dans des requêtes simples ou dans des phases d’exploration rapide de données, peuvent trouver ce style « pratique ». Qui a le temps de chercher le nom de la colonne quand on peut juste numéroter ? Mais demandez à un professionnel aguerri de la data, et il vous dira que ce n’est pas une pratique à suivre dans un environnement de production.
Pourquoi ? Parce que lorsque vous travaillez sur des applications critiques ou des rapports qui doivent respecter une norme, utiliser des numéros rend le code non seulement illisible, mais cela pose également un risque important en termes de maintenance. Si jamais l’ordre des colonnes dans votre instruction SELECT change, par exemple à la suite d’une mise à jour ou d’un changement dans la base de données, votre requête devient un champ de mines. Les bugs peuvent surgir sans crier gare, et les erreurs de tri pourraient coûter cher. Cela a déjà été vécu par de nombreux développeurs qui ont dû retourner en catastrophe sur leurs bases de données après qu’un simple changement ait perturbé tout un système.
Pour ceux qui aiment jouer avec leurs données sans trop réfléchir, OK, cela peut passer. Mais pour les professionnels qui gèrent des projets complexes, il vaut mieux éviter ces raccourcis aléatoires. Dites-vous que le génie des meilleurs développeurs n’est pas seulement dans leur capacité à produire du code, mais aussi dans leur capacité à le rendre lisible et maintenable. Et rappelons qu’une bonne pratique est toujours un bon investissement. Si vous voulez approfondir et comprendre pourquoi éviter ORDER BY 1,2, n’hésitez pas à consulter ce cours sur SQL. Vous vous remercierez plus tard !
Que retenir pour améliorer mes requêtes SQL et éviter les pièges
Si vous êtes encore à utiliser ORDER BY 1,2 dans vos requêtes SQL, il est grand temps de revisiter cette pratique – et de la balayer comme on balayerait un vieux nez de porcelaine. Pourquoi ? D’abord, pour des raisons de lisibilité, ensuite pour la fiabilité et enfin, pour faciliter la maintenance des requêtes. Imaginez un collègue qui, des années après, you’d il se pleurerait d’utiliser cette méthode obscure sans comprendre pourquoi il obtient les résultats qu’il a. Un peu comme un magicien sans son chapeau, ça fait désordre, non ?
Utiliser des chiffres pour désigner vos colonnes, c’est un peu comme donner à votre chien un nom que seul vous comprenez. Vous vous retrouvez avec une belle complication en termes de compréhension. En production, la clarté prime sur l’obscure efficacité. En précisant les noms des colonnes, vous facilitez la lecture et la compréhension immédiate de vos intentions. Cela veut dire moins de temps passé à déchiffrer le code et plus de temps à faire des miracles avec vos données.
Et quand on parle de maintenance, n’oublions pas que nous tous, un jour, nous devenons des victimes de notre propre code. Si une requête où vous avez utilisé ORDER BY 1,2 doit être modifiée, attendez-vous à un travail d’enquête digne d’un Sherlock Holmes. Ce n’est pas cela qui vous fera gagner du temps.
- Lisibilité : utilisez toujours les noms de colonnes explicites.
- Fiabilité : intégrer des modifications dans des requêtes claires est plus simple.
- Maintenance : le code est plus facile à gérer pour vous et vos collègues.
Pour vous aider dans cette quête d’excellence, voici une check-list simple pour écrire des requêtes solides, en particulier sur le tri :
- Utilisez toujours les noms de colonnes dans vos clauses ORDER BY.
- Évitez les champs positionnels comme 1, 2 ou 3.
- Vérifiez que l’ordre de tri est cohérent avec le contexte des données.
- Testez vos requêtes avant de les déployer en production.
- Documentez vos requêtes pour que vos collègues sachent ce que vous avez fait.
En résumé, bannir ORDER BY 1,2 de votre arsenal SQL, c’est comme passer d’un petit scooter à une voiture de sport. C’est plus rapide, plus efficace, et surtout, ça vous évite des ralentissements indésirables. Voici un tableau de synthèse pour vous rappeler les bonnes pratiques :
| Bonne Pratique | Description |
|---|---|
| Éviter l’usage des codes numériques | Favoriser des noms de colonnes dans ORDER BY. |
| Tester la requête | Vérifier l’exactitude du tri avant mise en production. |
| Documentation | Expliciter les intentions de tri dans le code. |
Alors, prêt à abandonner ORDER BY 1,2 et coder enfin propre ?
ORDER BY 1,2, c’est le raccourci toxique du SQL qui tente de sauver quelques frappes mais conduit au chaos quand vous modifiez vos requêtes. En utilisant toujours les noms explicites des colonnes pour trier, vous améliorez la lisibilité, évitez les bugs sournois, et facilitez la maintenance dans vos projets, surtout en production. Pour tout professionnel sérieux, renoncer à ORDER BY position, c’est adopter une habitude simple mais déterminante qui protège votre code et votre business. Vous l’aurez compris, derrière cette précaution, c’est la stabilité et la robustesse de vos données qui gagnent.
FAQ
Pourquoi ORDER BY 1,2 est déconseillé en SQL ?
Peut-on utiliser ORDER BY 1 dans des cas simples ?
Comment rendre mes ORDER BY plus robustes ?
Quels problèmes concrets ORDER BY 1 provoque-t-il ?
Y a-t-il des alternatives plus sûres à ORDER BY 1,2 ?
A propos de l’auteur
Franck Scandolera, expert en Web Analytics et Data Engineering, accompagne depuis plus de 10 ans les professionnels dans l’exploitation intelligente de leurs données. Responsable de l’agence webAnalyste et formateur dédié à la maîtrise des outils comme BigQuery et SQL, il prône des pratiques robustes et durables, évitant les pièges classiques et souvent ignorés du langage SQL. Son expérience terrain auprès d’agences et d’annonceurs européens garantit un savoir-faire concret en optimisation de requêtes et structuration fiable de données.
⭐ 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.