Hmm, voici un résultat surprenant. Je n'ai pas SQL Server ici, donc j'ai essayé cela dans Postgres. Évidemment, les clauses de non-responsabilité s'appliquent: cela ne donnera pas nécessairement les mêmes résultats, votre kilométrage peut varier, consultez un médecin avant de l'utiliser. Mais encore ...
je viens d'écrire une requête simple de deux façons différentes:
select *
from foo
where (select code from bar where bar.barid=foo.barid) between 'A' and 'B'
et
select *
from foo
where (select code from bar where bar.barid=foo.barid)>='A'
and (select code from bar where bar.barid=foo.barid)<='B'
Étonnamment pour moi, tous les deux avaient des temps d'exécution presque identiques. Quand j'ai fait un PLAN EXPLAIN, ils ont donné des résultats identiques. Plus précisément, la première requête a fait la recherche sur la barre deux fois, une fois pour le test> = et encore pour le test < =, tout comme la deuxième requête. Conclusion: Dans Postgres, au moins, BETWEEN n'est en effet que du sucre syntaxique.
Personnellement, je l'utilise régulièrement car il est plus clair pour le lecteur, surtout si la valeur testée est une expression. Déterminer que deux expressions complexes sont identiques peut être un exercice non trivial. Comprendre que deux expressions complexes DEVRAIENT être identiques même si elles ne le sont pas est encore plus difficile.
Je n'étais même pas au courant qu'il y avait un opérateur entre. En regardant pour la première fois ce n'était pas 100% clair pour moi si entre être inclusif ou exclusif. Je l'ai deviné juste mais depuis, les réponses disent qu'il n'y a pas de différence de performance, je m'en tiendrai à la deuxième version pour le rendre plus clair. Cependant, je suis le type de personne qui ajoutera des parenthèses là où elles ne sont pas nécessaires juste pour être sûr qu'il n'y a aucun malentendu quand quelqu'un d'autre lit mon code. – drs9222