ORDER BY avec des positions ordinales (ex : ORDER BY 1, 2) peut sembler pratique mais introduit bugs, opacité et fragilité dans vos requêtes SQL. Décortiquons pourquoi cette mauvaise habitude est à fuir absolument dès que vos requêtes gagnent en complexité.
3 principaux points à retenir.
- Lisibilité réduite : ORDER BY 1 est cryptique, préférez le nom de colonne.
- Maintenance casse-gueule : modifier la liste SELECT change le tri et génère des erreurs.
- Résultats imprévisibles : déplacement ou ajout de colonnes modifie l’ordre sans avertissement.
Qu’est-ce que l’ORDER BY avec positions ordinales en SQL
Plongeons dans le vif du sujet : qu’est-ce que ce fameux ORDER BY avec positions ordinales en SQL ? Imaginez que vous êtes dans un restaurant. Le serveur vous demande comment vous souhaitez que les plats soient servis, et vous répondez : « Mettez d’abord le premier plat, puis le deuxième! ». C’est exactement ce que fait ORDER BY 1, 2 dans une requête SQL. Au lieu de désigner les colonnes par leur nom, on les appelle par leur position dans la liste des colonnes sélectionnées.
Cette syntaxe, bien que séduisante par son côté minimaliste, peut vous causer quelques sueurs froides. Prenons un exemple simple avec une table fictive clients contenant les colonnes nom, age, et ville. Si vous écrivez la requête suivante :
SELECT nom, age, ville FROM clients ORDER BY 1, 2;Vous demanderez à la base de données de trier les résultats d’abord par le nom, puis par age. Super, à première vue ! Mais maintenant, considérons la même requête, formulée de manière plus explicite :
SELECT nom, age, ville FROM clients ORDER BY nom, age;On aboutit au même résultat, mais l’avantage ici est la clarté. Dans une base comme PostgreSQL, MySQL ou même BigQuery, bien que les deux syntaxes soient acceptées, la version avec positions ordinales peut prêter à confusion, surtout dans le cadre de code complexe ou lorsque des colonnes sont ajoutées ou modifiées. Imaginez une requête où vous avez ajouté une colonne supplémentaire. Où en êtes-vous avec “ORDER BY 1, 2” ? C’est comme essayer de suivre un livre avec des pages mélangées. Le désordre s’installe rapidement, et la lisibilité de votre code en prend un coup.
En résumé, bien que cette syntaxe soit valide, elle pose de réels problèmes de maintenabilité, surtout dans des projets à long terme où les requêtes évoluent. Au final, pourquoi ne pas opter pour la clarté ? Le code, c’est comme un bon whisky : ça se savoure mieux quand on peut identifier les saveurs !
Pourquoi l’ORDER BY par position est problématique
Utiliser une position ordinale dans un ORDER BY, comme ORDER BY 1, c’est un peu comme choisir de covoiturer sans jamais connaître la destination. Ça semble pratique sur le moment, mais imaginez les conséquences sur le long terme ! Évidemment, cela pose trois problèmes majeurs : lisibilité, maintenance et fiabilité.
Quand on écrit ORDER BY 1, on fait un grand pas vers l’incompréhensible. Pourquoi ? Parce que derrière ce « 1 », il y a une colonne que vous avez sélectionnée. Mais laquelle ? Autant faire du tirage au sort. Lisez plutôt : ORDER BY id est clair comme de l’eau de roche. Qui, en passant par là, ne préférerait pas savoir exactement sur quoi on se base ? En cas de relecture ou de collaboration, cette netteté devient essentielle. Imaginez le développeur de demain, découvrant votre requête : il se gratte la tête en se demandant pourquoi est-ce que le tri se fait sur cette mystérieuse première colonne.
Passons au cœur du sujet : un simple ajout ou suppression de colonne dans la clause SELECT peut modifier le sens complet de votre requête ! Si vous aviez, par exemple, une colonne nom et que vous décidez de l’enlever, bingo ! Votre ORDER BY 1, qui était censé trier par id, pourrait maintenant trier par une colonne totalement inappropriée sans que vous le sachiez. Quel cadeau empoisonné, n’est-ce pas ? Cela peut générer des bugs sournois en production, des cauchemars pour les développeurs et les utilisateurs, qui se retrouvent avec des résultats complètement décalés.
Dans les environnements critiques ou les pipelines de données robustes, cette pratique est donc largement découragée. Prenons un exemple : un incident dans une entreprise de finance où un rapport devait trier les clients par leur montant de dépenses. Un ORDER BY 1 a fini par trier par une colonne de dates, ce qui a causé des erreurs de plus de 100 000 euros dans les analyses. Une petite négligence qui coûte cher ! Bref, soyez avisé et optez pour la clarté. C’est en choisissant la transparence que vous garantissez la robustesse de vos applications.
Comment bien utiliser ORDER BY en SQL pour plus de robustesse
Répondre immédiatement : préférez toujours trier par noms explicites de colonnes pour garantir lisibilité et stabilité. En effet, utiliser un ORDER BY basé sur des positions ordinales, c’est comme jouer à la roulette russe avec vos données – le risque de tirage est réel, et les conséquences peuvent être dévastatrices. Pourquoi ? Parce qu’au gré des modifications de votre requête, la position de vos colonnes pourrait changer sans crier gare. Puis voilà, vous jouez aux devinettes avec votre propre code.
Alors, quelles sont les bonnes pratiques pour écrire un ORDER BY clair et sûr ? Voici quelques principes de base à suivre :
- Nom explicite des colonnes : Au lieu de dire « ORDER BY 1 », dites « ORDER BY nom_colonne ». Ça a du sens, n’est-ce pas ?
- Utilisez des alias explicites : Un bon alias peut transformer un SELECT en un poème. Par exemple, si vous utilisez SELECT nom AS ‘Nom Client’, n’oubliez pas d’utiliser le même alias dans votre ORDER BY.
- Évitez les dépendances sur la position physique : Pourquoi compter sur la position, alors que les noms de colonnes sont fixés et sans ambiguïté ?
Voici un exemple de requête SQL dans BigQuery qui illustre ces principes :
SELECT nom_client, montant_achat
FROM ventes
ORDER BY montant_achat DESC
Dans cette requête, nous trions les achats par montant, en utilisant des noms explicites plutôt que des positions. Ça donne envie de s’y plonger, n’est-ce pas ? En plus, comment pouvez-vous être certain que montant_achat ne changera pas de place dans le SELECT ? Les colonnes, c’est sacré !
Maintenant, parlons des alias dans votre ORDER BY. Quand vous utilisez un alias, n’oubliez pas qu’ils sont également sujets à des ajustements dans le temps. Gardez les noms cohérents et intuitifs pour faciliter la maintenance de vos requêtes. Pensez à ceux qui liront votre code dans trois mois, ne leur faites pas endurer des casse-têtes !
Pour finir, voici un tableau synthétique comparant les avantages et inconvénients de ORDER BY par ordinale versus nom de colonne :
| Méthode | Avantages | Inconvénients |
|---|---|---|
| Ordinale | Simplicité dans les petites requêtes | Risques d’erreurs lors de modifications |
| Nom de colonne | Clarté, stabilité à long terme | Légèrement plus verbeux |
Pour une bonne gestion du code, choisissez la clarté plutôt que la concision. En fin de compte, un bon code, c’est un code que l’on comprend facilement ! Comme on dit, « La simplicité est la sophistication suprême » – Léonard de Vinci aurait approuvé !
Alors, pourquoi prendre le risque avec ORDER BY par positions ?
Fuir l’usage d’ORDER BY avec des positions ordinales est un réflexe salutaire pour tout professionnel de la Data et du SQL. Cette pratique, bien que tentante pour économiser quelques frappes, sème l’opacité, fragilise la maintenance, et peut produire des résultats incohérents au moindre changement. Privilégier les noms explicites de colonnes dans ORDER BY améliore radicalement la robustesse, la clarté et la sécurité de vos requêtes. À terme, cela vous fera gagner du temps, du calme et vous évitera des crises de nerfs à diagnostiquer des bugs sournois. En somme, un peu de rigueur supprime beaucoup de galère.
FAQ
Qu’est-ce que l’ORDER BY avec positions ordinales en SQL ?
Pourquoi éviter d’utiliser ORDER BY avec des positions ordinales ?
Est-il toujours possible d’utiliser ORDER BY 1, 2 ?
Quels sont les risques en production avec ORDER BY par position ?
Comment écrire un ORDER BY robuste et clair en SQL ?
A propos de l’auteur
Responsable de l’agence webAnalyste et formateur expert en SQL, data engineering et automation, j’accompagne depuis plus de dix ans agences et entreprises à structurer leurs données fiables et performantes. Passionné par BigQuery et le SQL, je partage méthodes pragmatiques pour écrire des requêtes claires, maintenables et robustes, indispensables dans les environnements complexes. Ma priorité : transformer la donnée brute en un outil business fiable et accessible, sans faux-semblants techniques.
⭐ Expert et formateur en Tracking avancé, Analytics Engineering et Automatisation IA (n8n, Make) ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, 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.