Trier par positions ordinales (ORDER BY 1,2) en SQL est possible, mais risqué : c’est illisible, fragile et source d’erreurs quand la structure change. Voici pourquoi privilégier les noms de colonnes pour un SQL robuste et clair.
3 principaux points à retenir.
- Lisibilité : Ordre par colonne est plus clair qu’utiliser un simple 1 ou 2.
- Maintenance : Modifier le SELECT peut invalider l’ordre si on trie par position.
- Fiabilité : Requêtes peuvent donner des résultats inattendus si l’ordre des colonnes change.
Comment fonctionne ORDER BY avec des positions ordinales en SQL
La commande ORDER BY en SQL, c’est un peu le chef d’orchestre de vos données. Souhaitez-vous que votre symphonie de résultats soit jouée dans un ordre maîtrisé ? Aucun problème ! Une de ses particularités, c’est d’accepter des numéros de colonne pour trier – simple et efficace. Oui, ces fameuses positions ordinales, qui paraissent presque magiques par leur simplicité. Imaginez un peu : vous voulez trier par la première colonne de votre requête. Eh bien, un petit ORDER BY 1, et le tour est joué. Ce chiffre fait référence à la position de la colonne dans la liste de votre clause SELECT.
Regardons un exemple concret. Supposons que vous ayez une table clients et que vous souhaitiez trier par le nom de famille, qui est la troisième colonne dans votre sélection :
SELECT id, prénom, nom, ville FROM clients ORDER BY 3;Dans ce cas, la requête tri les résultats par le nom de famille, même si, théoriquement, on pourrait avoir l’impression d’invoquer une sorte de sortilège en parlant simplement du chiffre « 3 ». Ça fonctionne dans la plupart des moteurs SQL, en effet. MySQL, PostgreSQL, SQL Server et même Oracle supportent cette fonctionnalité, ce qui explique pourquoi tant de développeurs se laissent séduire par cette approche… un peu trop facile, n’est-ce pas ?
Il y a quelque chose de séduisant dans le fait de ne pas avoir à taper le nom complet d’une colonne. Cela pourrait sembler être un gain de temps. En revanche, nous verrons bientôt que cette simplicité peut avoir ses revers, car une petite maladresse dans cette approche pourrait vous coûter cher. Qui ne veut pas éviter les pièges cachés de l’ORDRE ? On pourrait presque le nommer « L’Antichambre des Erreurs » dans le vaste monde du SQL.
Quand vous utilisez des positions ordinales, ne perdez pas de vue que votre requête peut devenir peu lisible, tant pour vous que pour vos collègues. Mais bon, gardons cela pour plus tard. Pour l’instant, savourez la facilité d’utilisation des positions ordinales sous le doux ciel SQL. Mais croyez-moi, la suite ne vous laissera pas indifférent. Il y a des histoires à raconter sur leurs défauts qui vous donneront matière à réflexion.
Quels sont les dangers réels d’utiliser les positions ordinales dans ORDER BY
Utiliser des positions ordinales dans une clause ORDER BY en SQL, c’est comme naviguer en pleine tempête avec une boussole qui indique toujours le Nord, même quand vous voulez aller au Sud. Ça fait joli dans le code, mais la réalité, c’est que ça devient vite le cauchemar de l’angoissé du système. Détaillons les dangers qui se cachent derrière cette pratique.
1. Lisibilité réduite: Quand vous croisez un ORDER BY 1, il n’y a qu’un mot qui traverse l’esprit : pourquoi ? Ça ne parle pas, ça ne vend pas. Alors que ORDER BY id est on ne peut plus clair. Penser à un collègue (ou à vous-même !) cherchant le sens d’un code illisible, c’est s’exposer à des migraines assurées lors des sessions de debug. Qui aurait envie de passer son temps à déchiffrer une énigme posée par d’autres ? C’est ce qu’on appelle “faire le grand écart vers l’inefficacité”.
2. Fragilité accrue: Imaginez, un jour, votre colonne nom prend la place de id dans la liste de votre SELECT. Pas de souci, vous êtes encore là… jusqu’à ce que vous vous rendiez compte que votre ORDER BY 2 trahit votre requête. Voilà, vous avez juste décapité votre SQL, et c’est l’arbitre qui siffle la fin du match sans expliquer pourquoi ! La fragilité due aux positions ordinales est comparable à jouer à un casse-brique avec une balle de tennis : plaisant au début, mais rapidement frustrant !
3. Résultats erronés: Si vous ajoutez, supprimez ou réorganisez des colonnes dans votre SELECT, sans revoir vos positions ordinales, préparez-vous à des révélations surprenantes (ou désastreuses). Prenons un exemple. Supposons que vous ayez :
SELECT id, nom, age FROM clients ORDER BY 1;Un beau jour, vous décidez d’intercaler une colonne email entre nom et age. Attendez-vous à voir vos données dans un beau désordre. Le résultat va tirer un grand trait sur la fiabilité des infos récupérées, laissant vos critères de tri en slip sur le côté de la route.
Pour les experts comme Tamas Ujhelyi, la question est simple : privilégiez la clarté, cela fait gagner un temps fou. Après tout, la vie est trop courte pour se casser la tête sur des querelles ordinales. En fin de compte, adopter de meilleures pratiques SQL comme ceux-là fait de notre code une œuvre d’art plutôt qu’un gribouillage d’enfant. Les mots d’ordre sont : visibilité, contrôle et pérennité.
N’oubliez pas : en SQL, comme dans la vie, il vaut mieux « tracer sa route » que de « suivre les flèches » (même si parfois c’est tentant). Pour plus d’infos solides sur le sujet, consultez cet article.
Comment bien trier en SQL pour éviter ces pièges et écrire un code propre
Quand il est question de trier en SQL, une des règles d’or devrait être l’utilisation des noms de colonnes dans la clause ORDER BY. Imaginez-vous un peu : vous venez de rédiger une requête qui fait appel à plusieurs colonnes et, dans le feu de l’action, au lieu d’opter pour une approche lisible, vous avez choisi de jouer à Twister avec les positions ordinales. Voici un petit rappel : ce n’est pas parce que c’est possible que c’est toujours judicieux.
En utilisant des noms de colonnes, vous vous assurez d’une clarté indiscutable qui facilite la maintenance de votre code. En cas de modification ultérieure de la requête, une simple modification de la colonne suffit, sans trop de complications. Cela réduit aussi le risque d’accidents causés par des changements dans l’ordre des colonnes dans la clause SELECT, qui peuvent transformer un ORDER BY 1 inoffensif en un véritable désastre !
Voici un exemple pour illustrer cela :
-- Trier par position ordinal
SELECT nom, age, ville FROM utilisateurs ORDER BY 2;
-- Trier par nom de colonne
SELECT nom, age, ville FROM utilisateurs ORDER BY age;Dans le premier cas, notre ami le ORDER BY 2 fait référence à la colonne age, mais qu’adviendra-t-il si dans le futur, vous décidez d’ajouter une nouvelle colonne avant ? Cela compliquerait tout ! Avec le second exemple, même si la structure change, ORDER BY age est là, bien en place, comme un phare dans la nuit de la data.
Ne vous arrêtez pas là ! N’oubliez pas aussi d’utiliser des alias si vous traitez des colonnes dérivées ou calculées. Cela vous permettra d’avoir un code encore plus lisible. Au lieu de donner l’impression que l’on parle en charabia, vous invitez le lecteur à une discussion intelligible.
| Méthode | Avantages | Inconvénients |
|---|---|---|
| ORDER BY Position Ordinale | Code court | Risque de confusion, dépend des colonnes |
| ORDER BY Noms de Colonnes | Clarté, robustesse, maintenable | Peut être plus long |
Pour parfaire votre compréhension, n’hésitez pas à plonger dans la documentation de Microsoft sur la clause ORDER BY. Elle regorge de détails qui enrichiront votre expertise et vous éviteront de mordre dans la poussière à cause d’un code fouillis !
Faut-il vraiment abandonner les positions ordinales dans ORDER BY en SQL
Utiliser les positions ordinales dans ORDER BY peut sembler pratique au départ, mais c’est un piège sournois qui complique la maintenance et nuit à la fiabilité de vos requêtes. Privilégier le tri par nom de colonne évite les mauvaises surprises, améliore la lisibilité et sécurise votre code sur le long terme. Vous y gagnez en robustesse et sérénité, ce qui est justement le but quand on travaille les données sérieusement.
FAQ
Qu’est-ce que trier par positions ordinales dans ORDER BY ?
Pourquoi éviter ORDER BY 1, 2 dans mes requêtes SQL ?
Utiliser les noms de colonnes améliore-t-il vraiment la lisibilité ?
Y a-t-il des cas où ORDER BY position est acceptable ?
Comment éviter les erreurs liées au tri dans mes requêtes SQL ?
A propos de l’auteur
Franck Scandolera, consultant expert en Web Analytics, Data Engineering et automatisation, accompagne depuis plus de dix ans des professionnels dans la maîtrise du traitement des données. Responsable de l’agence webAnalyste et formateur indépendant, il démocratise les bonnes pratiques du SQL et des outils analytiques (BigQuery, GA4) avec une approche pragmatique et axée résultats business.