SQL: ENTRE vs <= e> =

Question

No SQL Server 2000 e 2005:

• qual é a diferença entre estas duas cláusulas WHERE?
• que eu deveria usar em que 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'

(Edit: o segundo EVENTDATE foi originalmente faltando, então a consulta foi sintaticamente errado)

Answer 1

Eles são idênticos: BETWEEN é um atalho para o longo sintaxe na pergunta.

Use uma mais sintaxe alternativa onde BETWEEN não funciona por exemplo.

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

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

Answer 2

Eles são os mesmos.

Uma coisa que ter cuidado, é se você estiver usando isso contra um DATETIME, a partida para a data final será o começo do dia:

<= 20/10/2009

não é o mesmo que:

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

(ele faria partida contra <= 20/10/2009 00:00:00.000)

Answer 3

Embora BETWEEN é fácil de ler e manter, eu raramente recomendar o seu uso, porque é um intervalo fechado e, como mencionado anteriormente, isso pode ser um problema com datas -. Mesmo sem componentes de tempo

Por exemplo, quando se lida com dados mensais muitas vezes é comum para comparar datas BETWEEN first AND last, mas na prática isso é geralmente mais fácil de escrever dt >= first AND dt < next-first (que também resolve o problema a tempo parcial) - uma vez que a determinação last normalmente é um passo maior do que a determinação next-first (subtraindo um dia).

Além disso, um outro apanhado é que o limite inferior e superior não precisam de ser especificadas na ordem correcta (isto é BETWEEN low AND high).

Answer 4

Normalmente, não há diferença -. A palavra-chave BETWEEN não é suportado em todas as plataformas RDBMS, mas se for, as duas consultas devem ser idênticos

Uma vez que eles são idênticos, não há realmente nenhuma distinção em termos de velocidade ou qualquer outra coisa -. Usar o que parece mais natural para você

Answer 5

Como mencionado por @marc_s, @Cloud, et al. eles são basicamente o mesmo para uma gama fechada.

Mas quaisquer valores de tempo fracionárias podem causar problemas com um intervalo fechado (mais-ou-iguais e menos-ou-igual ), em oposição a uma gama semi-aberto (maior-ou-igual e menos do que ) com um valor final após o último possível instante.

Então, para evitar que a consulta deve ser reescrita como:

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

Desde BETWEEN não funciona para intervalos semi-aberto que eu sempre tomar um duro olhar para qualquer consulta de data / hora que o utiliza, desde o seu provavelmente um erro.

Answer 6

Eu acho que a única diferença é a quantidade de açúcar sintático em cada consulta. ENTRE é apenas uma maneira lisa de dizer exatamente o mesmo que a segunda consulta.

Pode haver alguma diferença RDBMS específico que eu não estou ciente de, mas eu realmente não penso assim.

Answer 7

Eu tenho uma ligeira preferência por BETWEEN porque torna imediatamente claro para o leitor que você está verificando um campo para uma gama . Isto é especialmente verdadeiro se você tem nomes de campos semelhantes na sua tabela.

Se, por exemplo, a nossa mesa tem tanto um transactiondate e uma transitiondate, se eu ler

transactiondate between ...

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

Se eu ler

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

Eu tenho que tomar um momento extra para certificar-se os dois campos são os mesmos.

Além disso, como uma consulta fica editado ao longo do tempo, um programador descuidado pode separar os dois campos. Eu 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 tentam isso com um BETWEEN, é claro, será um erro de sintaxe e prontamente fixas.

Answer 8

Logicamente há nenhuma diferença em tudo. Em termos de performance há -typically, na maioria DBMSes- nenhuma diferença em tudo.

Answer 9

Veja este excelente blog de Aaron Bertrand sobre o porquê você deve mudar seu formato de cadeia e como os valores limite são tratados em consultas de intervalo de datas.

Answer 10

Disclaimer: Tudo abaixo é apenas anedótica e tiradas diretamente de minha experiência pessoal. Qualquer um que sente-se em conduzir uma análise mais rigorosa empiricamente é bem-vinda para realizá-lo e para baixo voto se eu sou. Também estou ciente de que o SQL é uma linguagem declarativa e você não deveria ter que considerar como seu código é processado quando você escrevê-lo, mas, porque eu valorizo ??meu tempo, eu faço.

Há declarações logicamente equivalentes infinitas, mas eu vou considerar três (ish).

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

A> = MinBound E A <= MaxBound

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

A ENTRE MinBound E MaxBound

Caso 3: duas comparações em uma ordem educado (ordem de avaliação escolhida no momento da gravação)

A> = MinBound E A> = MaxBound

ou

A> = MaxBound E A> = MinBound

Na minha experiência, Caso 1 e Caso 2 não tem nenhum diferenças consistentes ou notáveis ??no desempenho como eles são dataset ignorante.

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

Um caso de uso que eu tenho é consultando um grande conjunto de dados histórico com datas não-indexados para registros dentro de um intervalo específico. Ao escrever a consulta, eu vou ter uma boa idéia da existência ou não de mais dados existe antes do intervalo especificado ou após o intervalo especificado e pode encomendar minhas comparações em conformidade. Eu tive tempos de execução cortado por tanto como meia, dependendo do tamanho do conjunto de dados, a complexidade da consulta, e da quantidade de registros filtrados pela primeira comparação.