Tous ces éléments sont fonctionnellement équivalents. Même la séparation entre la clause WHERE et la condition JOIN ne changera pas les résultats lorsque vous travaillez entièrement avec des jointures INNER (cela peut avoir de l'importance avec des jointures OUTER). De plus, tous ces éléments doivent correspondre exactement au même plan de requête (aucune différence de performances). L'ordre dans lequel vous incluez les éléments n'a pas d'importance . Le moteur de requête est libre d'optimiser comme il l'entend le mieux dans les spécifications fonctionnelles de la requête. Même lorsque vous identifiez un comportement spécifique en ce qui concerne l'ordre, vous ne devez pas compter dessus. La spécification permet au patch de demain de modifier le comportement d'aujourd'hui dans ce domaine. N'oubliez pas :tout l'intérêt de SQL est d'être basé sur des ensembles et déclaratif :vous dites à la base de données quoi vous voulez qu'il fasse, pas comment vous voulez qu'il le fasse.
Maintenant que l'exactitude et les performances sont à l'écart, nous en sommes aux questions de style :des choses comme la productivité du programmeur et la lisibilité/maintenabilité du code. À cet égard, l'option 4 de cette liste est de loin le meilleur choix, avec #3 le deuxième meilleur, surtout lorsque vous commencez à vous lancer dans des requêtes plus compliquées. N'utilisez simplement pas le A,B syntaxe plus ; il est obsolète depuis la version 1992 du standard SQL. Écrivez toujours le INNER JOIN complet (ou LEFT JOIN /RIGHT JOIN /CROSS JOIN etc.).
Cela dit, alors que l'ordre n'a pas (ou, du moins, ne devrait pas) avoir d'importance pour les performances, je trouve utile lorsque j'écris SQL d'utiliser une convention dans mon approche qui dicte l'ordre. Cela m'aide à identifier les erreurs ou les fausses hypothèses ultérieurement lors du débogage et du dépannage. Ce guide général que j'essaie de suivre est de se comporter comme si l'ordre avait de l'importance, puis dans cet esprit, essayez de garder l'ensemble de travail de mémoire nécessaire à la base de données pour répondre à la requête aussi petit que possible aussi longtemps que possible :commencez d'abord par des tables plus petites, puis rejoignez les plus grandes ; lors de l'examen de la taille de la table, tenez compte des conditions de la clause WHERE qui correspondent à un index ; préférez les jointures internes avant les externes lorsque vous avez le choix; répertorier les conditions de jointure pour favoriser les index (en particulier les clés primaires/cluster) en premier, et les autres conditions sur la jointure en second.
