Pourquoi éviter ORDER BY 1,2 en SQL pour trier les résultats ?

ORDER BY 1,2 trie vos résultats par positions ordinales, mais c’est un piège : moins lisible, fragile à la modification des colonnes, et source d’erreurs. Il vaut mieux utiliser les noms de colonnes pour un SQL robuste et maintenable. On vous explique pourquoi et comment faire mieux.

3 principaux points à retenir.

ORDER BY 1,2 réduit la lisibilité car on ne sait pas quelles colonnes sont triées.
Modifier la sélection casse votre tri ou produit des résultats inattendus.
Bonne pratique : préférez toujours les noms de colonnes dans ORDER BY.

Qu’est-ce que ORDER BY avec des positions ordinales en SQL ?

Quand on parle de SQL, l’expression ORDER BY 1, 2 fait souvent débat. Alors, qu’est-ce qui se cache derrière cette notation ? En clair, cela signifie que l’on va trier les résultats d’une requête en utilisant les positions ordinales des colonnes. On commence par la première colonne sélectionnée, puis on enchaîne avec la deuxième. Simple comme bonjour, non ? Mais la simplicité peut parfois avoir des conséquences inattendues.

Imaginons que vous ayez une table clients avec les colonnes nom, âge et ville. Si vous voulez trier par nom puis par âge, une requête classique pourrait ressembler à ceci :

SELECT nom, âge, ville FROM clients ORDER BY 1, 2;

Ce qui, en regardant de plus près, veut dire trier par nom (la première colonne) puis par âge (la deuxième). Facile, non ? Mais que se passe-t-il si dans un avenir proche, vous décidez d’ajouter une colonne supplémentaire, mettons code_postal ? Le jour où vous décidez de changer l’ordre des colonnes dans votre SELECT, hop, vous vous retrouvez avec un tri qui pourrait bien ne pas correspondre à votre intention initiale. Ouille !

Maintenant, voyons comment on ferait exactement la même chose mais avec des noms de colonnes explicites :

SELECT nom, âge, ville FROM clients ORDER BY nom, âge;

En utilisant des noms explicites, vous êtes à l’abri des surprises. Si vous rajoutez ou retirez des colonnes, votre tri reste intact. Pas de coups tordus ici ! Cela rappelle le sage conseil de Socrate : « La vérité est l’harmonie de l’âme. » Dans le monde de SQL, l’harmonie passe par des requêtes claires et compréhensibles.

Alors, à quoi bon se compliquer la vie avec ORDER BY 1, 2 ? Certes, cela peut sembler plus rapide, mais la fiabilité et la clarté devraient toujours primer. N’oublions pas : dans le monde de la data, chaque détail compte.

Quels sont les risques à utiliser ORDER BY 1,2 en production ?

L’utilisation d’ORDER BY par position (comme ORDER BY 1, 2) en production, c’est un peu comme mettre des œillères avant de monter à cheval. Ça peut sembler pratique sur le moment, mais il faut être conscient des dangers qui se cachent derrière cette méthode. Tenter de trier avec ces chiffres, c’est s’exposer à une lisibilité dégradée. Imaginez un développeur qui reprend votre code en espérant y trouver la clarté : il se retrouve face à un texte cryptique. Quel critère de tri est utilisé ? Mystère !

Et laissez-moi vous dire, la fragilité technique ne tarde pas à s’immiscer dans l’affaire. Si vous ajoutez, supprimez ou réordonnez des colonnes dans votre liste SELECT, qu’est-ce qui se passe ? Boum ! Le comportement de l’ORDER BY se transforme. Ce qui fonctionnait hier peut causer des maux de tête aujourd’hui. Des bugs, non détectés, font leur apparition. Prenez un exemple concret : vous avez une requête qui trie des résultats par nom à la position 1, mais si vous ajoutez une nouvelle colonne (disons, une adresse e-mail), c’est la colonne du nom qui passe à la position 2. Oups ! Vos résultats sont désormais triés par adresse e-mail sans que vous ne vous en rendiez compte. Et là, la requête, c’est le grand plongeon.

Les conséquences sont parfois désastreuses : des écarts dans les résultats ou, pire encore, un plantage de la requête complète. Imaginez deux développeurs, chacun ayant écrit des requêtes. Le premier utilise ORDER BY 1 et le deuxième se frotte à ORDER BY name. Quelles différences dans l’output ! La confusion est reine.

Alors, la question se pose : est-ce que vraiment ces quelques secondes gagnées à taper un ORDER BY par numéro vaut la peine de naviguer dans un océan de risques ? Absolument pas. La clarté et la maintenance du code en production doivent être vos priorités, et non pas une compétition sur qui peut taper le plus vite. Pour plus de détails sur les subtilités d’ORDER BY, n’hésitez pas à jeter un coup d’œil ici. Il est grand temps de faire la paix avec l’écriture explicite et de laisser de côté les abréviations ensorcelantes !

Comment écrire un ORDER BY robuste et lisible ?

Lorsque vous rédigez des requêtes SQL, le tri de vos résultats est une étape cruciale. Mais, oh là là, évitons le fameux ORDER BY 1, 2 ! Pourquoi ? Parce qu’un ORDER BY efficace commence par des noms de colonnes explicites. Imaginez-vous essayer de déchiffrer un ancien grimoire, où les variables ne sont que des numéros. Cela vous donnerait envie de chercher une sortie, n’est-ce pas ?

En utilisant des noms de colonnes dans votre clause ORDER BY, vous rendez votre requête non seulement plus claire, mais aussi beaucoup plus maintenable. Prenons un exemple concret :

SELECT nom, age, salaire FROM employes ORDER BY 1, 3;

Vous triez ici par nom puis par salaire, mais que se passerait-il si vous rajoutiez une nouvelle colonne, disons departement ? Ce serait alors un véritable casse-tête pour vous et vos collègues ! Au contraire, en utilisant :

SELECT nom, age, salaire, departement FROM employes ORDER BY nom, salaire;

Vous restez clair dans vos intentions. Chaque modification, chaque ajout sera géré avec un soubresaut de grâce.

Pour faire simple, voici un tableau comparatif de ces deux approches :

ORDER BY ordinal

Avantages : Rapide à écrire, convient pour les requêtes simples.
Inconvénients : Difficile à lire, entretien complexe, changement de structure risqué.

ORDER BY par noms

Avantages : Lisible, facile à maintenir et flexible en cas de changements.
Inconvénients : Un peu plus long à écrire, une fois habitué, c’est un jeu d’enfant !

En gros, choisis toujours la voie de la clarté. Ne soyez pas celui qui laisse les autres dans l’angoisse à cause d’un tri obscur. Pour des requêtes SQL qui durent et s’adaptent plus facilement, retenez ceci : si ce n’est pas explicite, ça ne servira pas ! Vous voilà armé pour rédiger des requêtes et pour piquer la curiosité de vos collègues. Vraiment, qui ne rêve pas de devenir un maestro des bases de données ? Pour plus d’infos, jetez un œil à cet article captivant sur ORDER BY !

Le rôle de la lisibilité et maintenance en SQL professionnel

Dans le monde du SQL, la lisibilité et la maintenabilité d’une requête ne sont pas de simples suggestions : c’est une exigence. En effet, imaginez un développeur du futur, en train de déchiffrer vos œuvres littéraires SQL. Alors, que préférez-vous qu’il découvre ? Un chef-d’œuvre clair comme de l’eau de roche ou un fatras de chiffres à la syntaxe si obscure qu’il croira avoir ouvert une boîte de Pandore ? Justement, le choix d’un ORDER BY explicite est crucial. Utiliser ORDER BY 1, 2 peut sembler séduisant, une sorte de raccourci qui vous fait gagner quelques frappes, mais en réalité, vous vous dirigez tout droit vers le précipice de la confusion.

Pour illustrer cela, prenons l’exemple suivant :

SELECT name, age FROM users ORDER BY 1;

Qui sait ce que représente « 1 » ? Qui a décidé que la première colonne serait l’âge et non le nom ? Au lieu d’être éclairé, votre interlocuteur sera perdu. Le résultat, c’est que la complexité du code augmente, rendant chaque modification plus hasardeuse et générant une dette technique à la hauteur des factures du dernier chantier de construction de votre maison.

Les bonnes pratiques en SQL sont là pour éviter de telles situations. Un code propre ne se limite pas à écrire des requêtes fonctionnelles. Il doit aussi être conçu pour être compris rapidement par un collègue, ou même par vous-même, six mois plus tard. Des requêtes auto-documentées, en affichant explicitement les colonnes, facilitent la collaboration, surtout dans des environnements automatisés où les erreurs peuvent s’accumuler comme les tartines de confiture sur un petit-déjeuner trop chargé.

Alors, la prochaine fois que vous serez tenté de taper ORDER BY 1, 2, souvenez-vous que même une petite économie de frappe est-elle vraiment à la hauteur des risques d’erreurs potentielles ? N’est-il pas préférable de miser sur la clarté et la durabilité de votre code ? Pour un guide pratique et approfondi, n’hésitez pas à consulter cet article sur l’ORDER BY en SQL.

Alors faut-il définitivement bannir ORDER BY 1,2 de vos requêtes SQL ?

ORDER BY avec positions ordinales est un piège facile à éviter. Il rend votre code illisible, fragile à toute modification, et peut provoquer des erreurs sournoises dans les résultats. En utilisant systématiquement les noms explicites des colonnes pour trier, vous construisez un SQL plus clair, robuste et plus fiable. Ce n’est pas juste une question d’esthétique, mais de pérennité et d’efficacité en production. Finies les surprises en modifiant un SELECT, fini le code incompréhensible pour vos collègues. Le gain de temps à taper un peu moins de caractères ne justifie pas la perte en qualité et stabilité de votre code.

FAQ

Qu’est-ce que signifie ORDER BY 1,2 en SQL ?

ORDER BY 1,2 signifie trier les résultats selon la première colonne sélectionnée, puis la deuxième dans la clause SELECT. Les chiffres indiquent la position des colonnes dans la sélection, pas leur nom.

Pourquoi utiliser ORDRE BY 1,2 est-il considéré comme une mauvaise pratique ?

Parce que ça rend le code difficile à lire, fragile à toute modification des colonnes et crée des erreurs inattendues qui peuvent casser la requête ou fausser les résultats.

Comment garantir un tri fiable et maintenable en SQL ?

En utilisant toujours les noms explicites des colonnes dans la clause ORDER BY, pour une syntaxe claire, lisible et qui ne dépend pas de la position des colonnes.

Dans quels contextes le tri par positions ordinales peut-il poser problème ?

Principalement dans les projets en production, où les requêtes évoluent souvent et sont maintenues par plusieurs personnes. Le tri par position peut alors produire des erreurs sournoises.

Y a-t-il des cas où ORDER BY 1,2 est acceptable ?

Dans du prototypage rapide ou des requêtes ponctuelles, ça passe, mais en production et à long terme, c’est à éviter pour éviter bugs et incompréhensions.

A propos de l’auteur

Franck Scandolera, consultant expert en Data Engineering et Analytics, accompagne depuis plus de dix ans des entreprises dans la conception de pipelines solides et la maîtrise du SQL avancé en production. Spécialiste de BigQuery et formateur reconnu, il forme régulièrement des équipes sur les bonnes pratiques SQL, l’automatisation des données et la qualité des requêtes. Basé à Brive-la-Gaillarde, il partage son expérience terrain pour rendre le traitement des données clair, maintenable et efficace dans des environnements professionnels exigeants.

Franck Scandolera

⭐ 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.