SQL : ENTRE vs <= et >=

Dans SQL Server 2000 et 2005:

  • quelle est la différence entre ces deux WHERE clauses?
  • lequel je dois utiliser sur des scénarios?

Requête 1:

SELECT EventId, EventName
FROM EventMaster
WHERE EventDate BETWEEN '10/15/2009' AND '10/18/2009'

Requête 2:

SELECT EventId, EventName
FROM EventMaster
WHERE EventDate >='10/15/2009'
  AND EventDate <='10/18/2009'

(Edit: la deuxième Eventdate était à l'origine manquante, de sorte que la requête est syntaxiquement incorrect)

  • C'est un quasi doublon avec stackoverflow.com/questions/1572840/sql-between-v1-and-v2
  • pas vraiment, le traitement en question est légèrement différente, en plus c'était pour SQL server 2008, et il n'existe aucun moyen Shyju peut être certain sans demander que la réponse serait la même pour les versions précédentes.
InformationsquelleAutor Shyju | 2009-10-27
  1. 99

    Ils sont identiques: BETWEEN est un raccourci pour la plus de la syntaxe dans la question.

    Utiliser une alternative plus la syntaxe où BETWEEN ne fonctionne pas par exemple

    Select EventId,EventName from EventMaster
where EventDate >= '10/15/2009' and EventDate < '10/18/2009'

    (Note < plutôt que <= dans la deuxième condition.)

    • Peut-être que vous devriez insister sur le point que la deuxième condition est de " <". Il m'a fallu un certain temps pour repérer la différence.
    • Je voudrais ajouter que je vous recommande fortement de ne jamais l'utiliser ENTRE moins de traiter avec le type de données de DATE ou, autrement, la garantie que vos valeurs datetime n'aura jamais une composante temporelle. Être conforme à ce propos le rendre moins probable que vous allez utiliser ENTRE par erreur à la place de >= et <, et d'obtenir certaines données dans la requête que vous ne vous en veux pas, ou penser que vous receviez une journée supplémentaire de données lorsque vous n'êtes pas...
    • Y aurait-il un compilateur deuxième étape ENTRE est converti en conditionnelles? Je comprends que c'est un peu pédant, mais y aurait-il une surcharge supplémentaire?
    • Comment peut-on dire qu'ils sont identiques si elles ne le sont pas?!?
    • parce qu'ils sont? Comment sont-ils pas?
    • OP demandé si <=, >= et ENTRE sont égaux. Pour vous dire que oui, mais dans votre note à la fin de vous dire non). Suis-je manqué quelque chose?!? '2016-09-19' <= CURDATE() AND '2016-09-19' >= CURDATE() va passer, CURDATE() BETWEEN '2016-09-19' AND '2016-09-19' ne sera pas.
    • En effet, vous êtes manque quelque chose ici! L'OP a demandé s'il y avait une différence entre between et >=, <= et je l'ai dit il n'y en a pas, ils sont identiques. Je suis ensuite allé à dire que pour un différentes condition comme >=, < (note: < pas <=), alors vous ne pouvez pas utiliser between. Je pense que j'ai ajouté que, en réponse à un commentaire qui m'a demandé de.
    • Pouvez-vous expliquer pourquoi (vous dites) "'2016-09-19' <= CURDATE() AND '2016-09-19' >= CURDATE() va passer, CURDATE() BETWEEN '2016-09-19' AND '2016-09-19' ne sera pas"?
    • Mais votre deuxième (<) exemple est exactement ce que ENTRE se comporte comme. Votre première (<=) on n'est pas de travail pour moi. J'ai googlé si <=,>= et ENTRE étaient identiques, trouvé cette réponse, changé mon code et trouvé un exemple qui me prouve qu'ils ne sont pas identiques ... c'est mon problème ici.
    • Je suis en désaccord! Voir techonthenet.com/sql_server/between.php
    • Étrange...je crois que j'ai confondu par la question, la rédaction de la réponse, les commentaires et le fait que mon code a évidemment un bug maintenant =)
    • Draguer le passé, je sais, mais ... @xmashallax: La deuxième version posté par Tony permet de tester à l'encontre des dates qui ont un élément de temps, même si la version affichée uniquement vérifier les dates de 2009/10/15 00:00:00 à 2009/10/17 23:59:59.999 (note: pas 2009/10/18 23:59:59.999) inclusivement. À l'aide de BETWEEN dans de telles circonstances serait de ne pas fonctionner correctement car c'est un inclusive (c >= et <=) opérateur; tous les enregistrements qui ont une valeur de date et heure de 2009/10/18 00:00:00 serait inclus dans le jeu de résultats.
    • Références: Microsoft Docs; W3 Écoles

    InformationsquelleAutor Tony Andrews
  2. 31

    Ils sont les mêmes.

    Une chose à faire attention, si vous utilisez cette contre un DATETIME, le match pour la date de fin sera le début de la journée:

    <= 20/10/2009

    n'est pas la même chose que:

    <= 20/10/2009 23:59:59

    (il serait match contre <= 20/10/2009 00:00:00.000)

    • Vous pouvez simplement utiliser entre '2009-10-20' et '2009-10-21', dans ce cas, la capture de la journée
    • ce serait aussi le match '2009-10-21 00:00:00.000' - probablement pas ce que vous voulez.
    • Vous voulez champ ENTRE '2009-10-20 00:00:00', ET '2009-10-20 23:59:59" ou champ >= '2009-10-20 00:00:00' ET le champ <= '2009-10-20 23:59:59' pour être absolument certain.
    • Vos exemples manquerait quelque chose qui s'est produite dans la dernière seconde de la journée... c'est à dire: entre 23:59:59 et 00:00:00 le jour suivant.
    InformationsquelleAutor Irfy
  3. 13

    Bien que BETWEEN est facile à lire et à maintenir, j'ai rarement recommander son utilisation, car il est un intervalle fermé et, comme mentionné précédemment, cela peut être un problème avec les dates - même, sans temps de composants.

    Par exemple, lors du traitement des données mensuelles, il est souvent commun à comparer des dates BETWEEN first AND last, mais dans la pratique, il est généralement plus facile d'écrire dt >= first AND dt < next-first (qui résout aussi le temps de la partie de l'émission) - car la détermination de last habituellement est une étape de plus que la détermination de next-first (par la soustraction d'un jour).

    En outre, un autre piège est que les limites inférieure et supérieure doivent être spécifiées dans le bon ordre (c'est à dire BETWEEN low AND high).

    • Mal. Ne pas répandre cette.
    InformationsquelleAutor Cade Roux
  4. 4

    Généralement, il n'y a pas de différence - le BETWEEN mot clé n'est pas pris en charge sur tous les SGBDR plates-formes, mais si il est, les deux requêtes doivent être identiques.

    Depuis qu'ils sont identiques, il n'y a vraiment pas de distinction en termes de vitesse ou quoi que ce soit d'autre - utiliser celui qui semble le plus naturel pour vous.

    InformationsquelleAutor marc_s
  5. 4

    Comme mentionné par @marc_s, @Cloud, et al. ils sont fondamentalement les mêmes pour une fermeture gamme.

    Mais les fractions de valeurs de temps peut provoquer des problèmes avec un fermé de gamme (plus grand ou égal et moins ou égal), par opposition à un demi-intervalle ouvert (plus grand ou égal et moins) avec une valeur de fin après au dernier instant.

    Pour éviter que la requête doit être réécrit comme suit:

    SELECT EventId, EventName
  FROM EventMaster
 WHERE (EventDate >= '2009-10-15' AND
        EventDate <  '2009-10-19')    /* <<<== 19th, not 18th */

    Depuis BETWEEN ne fonctionne pas pour les demi-ouvert intervalles je prends toujours un coup d'oeil dur à n'importe quelle date/heure de la requête qui utilise, car c'est probablement une erreur.

    InformationsquelleAutor devstuff
  6. 3

    Je pense que la seule différence est la quantité de sucre syntaxique sur chaque requête. ENTRE est juste un habile manière de dire exactement la même que la deuxième requête.

    Il pourrait y avoir certains SGBDR spécifique différence que je ne suis pas au courant, mais je ne crois pas vraiment.

    InformationsquelleAutor pyrocumulus
  7. 2

    Logiquement il n'y a pas de différence du tout.
    En terme de Performance il y a, en général, sur la plupart des DBMSes - pas de différence du tout.

    InformationsquelleAutor mjv
  8. 2

    Voir ce excellent post de blog de Aaron Bertrand pourquoi vous devriez changer votre format de chaîne de caractères et la façon dont les valeurs limites sont traitées dans la plage de dates des requêtes.

    • Lien déménagé à ici
    InformationsquelleAutor Andy Jones
  9. 2

    J'ai une légère préférence pour BETWEEN parce qu'il le rend instantanément clair pour le lecteur que vous archivez un champ pour une gamme. Cela est particulièrement vrai si vous avez semblable noms de champ dans votre table.

    Si, par exemple, notre tableau est à la fois un transactiondate et un transitiondate, si j'ai lu

    transactiondate between ...

    Je sais immédiatement que les deux extrémités de l'essai sont contre cette un terrain.

    Si j'ai lu

    transactiondate>='2009-04-17' and transactiondate<='2009-04-22'

    Je dois prendre un moment supplémentaire pour s'assurer que les deux champs sont les mêmes.

    Aussi, comme une requête est modifié au fil du temps, un mauvais programmeur peut séparer les deux domaines. J'ai vu beaucoup de requêtes qui disent quelque chose comme

    where transactiondate>='2009-04-17'
  and salestype='A'
  and customernumber=customer.idnumber
  and transactiondate<='2009-04-22'

    Si ils essayer cela avec une BETWEEN, bien sûr, ce sera une erreur de syntaxe et rapidement fixé.

    InformationsquelleAutor Jay
  10. 0

    Avertissement: Tout ce qui suit n'est qu'anecdotique et dessiné directement à partir de mon expérience personnelle. Toute personne qui se sent jusqu'à la réalisation d'une empiriquement plus rigoureux de l'analyse est la bienvenue à la réaliser et à la baisse de voter si je suis un. Je suis aussi conscient que le SQL est un langage déclaratif et vous n'êtes pas censé avoir à examiner la FAÇON dont votre code est traitée lorsque vous écrivez, mais, parce que j'estime mon temps, je le fais.

    Il existe d'infinies logiquement équivalent d'instructions, mais je vais envisager de trois(ish).

    Cas 1: Deux Comparaisons dans un standard order (ordre d'Évaluation fixe)

    A >= MinBound ET UN <= MaxBound

    Cas 2: sucre Syntaxique (ordre d'Évaluation n'est pas choisi par l'auteur)

    Un ENTRE MinBound ET MaxBound

    Cas 3: Deux Comparaisons dans l'éducation de la commande (ordre d'Évaluation choisi lors de l'écriture de l'époque)

    A >= MinBound ET A >= MaxBound

    Ou

    A >= MaxBound ET A >= MinBound

    Dans mon expérience, les Cas 1 et 2 n'ont aucune cohérence ou de notables différences dans la performance comme ils sont dataset ignorants.

    Toutefois, des Cas d'3 peut améliorer considérablement les temps d'exécution. Plus précisément, si vous travaillez avec un grand ensemble de données et arriver à avoir quelques heuristique de connaissances quant à savoir si Un est plus susceptible d'être plus grande que la MaxBound ou moindre que le MinBound vous pouvez améliorer les temps d'exécution sensiblement en utilisant le Cas 3, la commande des comparaisons en conséquence.

    Un cas d'utilisation j'ai, c'est l'interrogation historique jeu de données non indexées dates pour les enregistrements à l'intérieur d'un intervalle de temps spécifique. Lors de l'écriture de la requête, je vais avoir une bonne idée de savoir si ou non plus de données AVANT de l'intervalle de temps spécifié ou APRÈS l'intervalle de temps spécifié et peut ordonner mes comparaisons en conséquence. J'ai eu le temps d'exécution réduit de plus de moitié selon la taille du jeu de données, la complexité de la requête, et la quantité d'enregistrements filtrés par la première comparaison.

    InformationsquelleAutor LanchPad