SQL: BETWEEN vs <= e> =

No SQL Server 2000 e 2005:

• qual é a diferença entre essas duas WHEREcláusulas?
• qual devo usar em quais cenários?

Consulta 1:

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

Consulta 2:

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

(Editar: o segundo Eventdate estava ausente originalmente, então a consulta estava sintaticamente errada)

Eles são idênticos: BETWEENé uma abreviatura para a sintaxe mais longa na questão.

Use uma sintaxe alternativa mais longa onde BETWEENnão funcionar, por exemplo

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

(Observe em <vez de <=na segunda condição.)

Eles são os mesmos.

Deve-se ter cuidado: se você estiver usando isso em DATETIME, a correspondência para a data de término será o início do dia:

<= 20/10/2009

não é o mesmo que:

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

(ele iria corresponder contra <= 20/10/2009 00:00:00.000)

Embora BETWEENseja fácil de ler e manter, raramente recomendo seu uso porque é um intervalo fechado e, como mencionado anteriormente, isso pode ser um problema com datas - mesmo sem componentes de tempo.

Por exemplo, ao lidar com dados mensais, muitas vezes é comum comparar datas BETWEEN first AND last, mas na prática isso geralmente é mais fácil de escrever dt >= first AND dt < next-first(o que também resolve o problema da parte do tempo) - uma vez que determinar lastgeralmente é um passo mais longo do que determinar next-first(subtraindo um dia) .

Além disso, outra pegadinha é que os limites inferior e superior precisam ser especificados na ordem correta (ou seja, BETWEEN low AND high).

Normalmente, não há diferença - a BETWEENpalavra-chave não é suportada em todas as plataformas RDBMS, mas se for, as duas consultas devem ser idênticas.

Como eles são idênticos, não há realmente nenhuma distinção em termos de velocidade ou qualquer outra coisa - use aquele que parecer mais natural para você.

Conforme mencionado por @marc_s, @Cloud, et al. eles são basicamente os mesmos para um intervalo fechado.

Mas quaisquer valores de tempo fracionário podem causar problemas com um intervalo fechado (maior ou igual e menor ou igual ) em oposição a um intervalo semiaberto (maior ou igual e menor que ) com um valor final após o último instante possível.

Portanto, para evitar que a consulta seja reescrita como:

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

Como BETWEENnão funciona para intervalos semiabertos, sempre analiso cuidadosamente qualquer consulta de data / hora que o utilize, pois provavelmente é um erro.

Tenho uma ligeira preferência por BETWEENporque torna imediatamente claro para o leitor que você está verificando um campo para um intervalo . Isso é especialmente verdadeiro se você tiver nomes de campo semelhantes em sua tabela.

Se, digamos, nossa mesa tiver um transactiondatee um transitiondate, se eu ler

transactiondate between ...

Eu sei imediatamente que ambas as pontas do teste são contra esse campo.

Se eu ler

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

Preciso de um minuto extra para ter certeza de que os dois campos são iguais.

Além disso, à medida que uma consulta é editada ao longo do tempo, um programador desleixado pode separar os dois campos. Já vi muitas consultas que dizem algo como

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

Se eles tentarem fazer isso com um BETWEEN, é claro, será um erro de sintaxe e será corrigido imediatamente.

Acho que a única diferença é a quantidade de açúcar sintático em cada consulta. BETWEEN é apenas uma maneira inteligente de dizer exatamente o mesmo que a segunda consulta.

Pode haver alguma diferença específica de RDBMS da qual não estou ciente, mas realmente não acho.

Logicamente, não há diferença alguma. Em termos de desempenho, normalmente, na maioria dos SGBDs, não há diferença alguma.

Veja esta excelente postagem de Aaron Bertrand sobre por que você deve alterar o formato da string e como os valores limite são tratados em consultas de intervalo de datas.

Aviso Legal: Tudo abaixo é apenas anedótico e tirado diretamente de minha experiência pessoal. Qualquer pessoa que se sinta à vontade para conduzir uma análise empiricamente mais rigorosa é bem-vinda para realizá-la e votar contra, se eu for. Também estou ciente de que SQL é uma linguagem declarativa e você não deve considerar COMO seu código é processado ao escrevê-lo, mas, porque eu valorizo ​​meu tempo, eu sim.

Existem infinitas declarações logicamente equivalentes, mas considerarei três (ish).

Caso 1: duas comparações em uma ordem padrão (ordem de avaliação corrigida)

A> = MinBound AND A <= MaxBound

Caso 2: Açúcar sintático (a ordem de avaliação não é escolhida pelo autor)

A BETWEEN MinBound AND MaxBound

Caso 3: Duas comparações em uma ordem educada (ordem de avaliação escolhida no momento da escrita)

A> = MinBound AND A <= MaxBound

Ou

A <= MaxBound AND A> = MinBound

Na minha experiência, o Caso 1 e o Caso 2 não apresentam diferenças consistentes ou notáveis ​​no desempenho, pois ignoram o conjunto de dados.

No entanto, o Caso 3 pode melhorar muito os tempos de execução. Especificamente, se você estiver trabalhando com um grande conjunto de dados e tiver algum conhecimento heurístico sobre se A é mais provável que seja maior do que o MaxBound ou menor do que o MinBound, você pode melhorar os tempos de execução visivelmente usando o Caso 3 e ordenando as comparações adequadamente.

Um caso de uso que tenho é consultar um grande conjunto de dados históricos com datas não indexadas para registros dentro de um intervalo específico. Ao escrever a consulta, terei uma boa ideia se existem ou não mais dados ANTES do intervalo especificado ou DEPOIS do intervalo especificado e posso ordenar minhas comparações de acordo. Eu tive o tempo de execução reduzido pela metade, dependendo do tamanho do conjunto de dados, da complexidade da consulta e da quantidade de registros filtrados pela primeira comparação.

Neste cenário col BETWEEN ... AND ...e col <= ... and col >= ...são equivalentes.

O SQL Standard define também o predicado T461 Symmetric BETWEEN :

 <between predicate part 2> ::=
 [ NOT ] BETWEEN [ ASYMMETRIC | SYMMETRIC ]
 <row value predicand> AND <row value predicand>

O Transact-SQL não oferece suporte a esse recurso.

BETWEENrequer que os valores sejam classificados. Por exemplo:

SELECT 1 WHERE 3 BETWEEN 10 AND 1
-- no rows

<=>

SELECT 1 WHERE 3 >= 10 AND 3 <= 1
-- no rows

Por outro lado:

SELECT 1 WHERE 3 BETWEEN SYMMETRIC 1 AND 10;
-- 1

SELECT 1 WHERE 3 BETWEEN SYMMETRIC 10 AND 1
-- 1

Funciona exatamente como o normal, BETWEENmas após classificar os valores de comparação.

db <> demonstração de violino