SQL: ENTRE vs <= y> =

En SQL Server 2000 y 2005:

• ¿Cuál es la diferencia entre estas dos WHEREcláusulas?
• ¿Cuál debería usar en qué escenarios?

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: originalmente faltaba el segundo Eventdate, por lo que la consulta era sintácticamente incorrecta)

Son idénticos: BETWEENes una abreviatura de la sintaxis más larga de la pregunta.

Use una sintaxis alternativa más larga donde BETWEENno funcione, por ejemplo

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

(Tenga <en cuenta en lugar de <=en la segunda condición).

Ellos son iguales.

Una cosa a tener en cuenta es que si está usando esto contra un DATETIME, la coincidencia para la fecha de finalización será el comienzo del día:

<= 20/10/2009

no es lo mismo que:

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

(que podría coincidir en contra <= 20/10/2009 00:00:00.000)

Aunque BETWEENes fácil de leer y mantener, rara vez recomiendo su uso porque es un intervalo cerrado y, como se mencionó anteriormente, esto puede ser un problema con las fechas, incluso sin componentes de tiempo.

Por ejemplo, cuando se trata de datos mensuales, a menudo es común comparar fechas BETWEEN first AND last, pero en la práctica esto suele ser más fácil de escribir dt >= first AND dt < next-first(lo que también resuelve el problema de la parte del tiempo), ya que determinar lastgeneralmente es un paso más largo que determinar next-first(restando un día) .

Además, otro problema es que los límites inferior y superior deben especificarse en el orden correcto (es decir BETWEEN low AND high).

Normalmente, no hay diferencia: la BETWEENpalabra clave no es compatible con todas las plataformas RDBMS, pero si lo es, las dos consultas deben ser idénticas.

Dado que son idénticos, realmente no hay distinción en términos de velocidad o cualquier otra cosa: use el que le parezca más natural.

Como lo mencionó @marc_s, @Cloud, et al. son básicamente los mismos para un rango cerrado.

Pero cualquier valor de tiempo fraccionario puede causar problemas con un rango cerrado (mayor o igual y menor o igual ) en lugar de un rango medio abierto (mayor o igual y menor que ) con un valor final después del último instante posible.

Entonces, para evitar que la consulta deba reescribirse como:

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

Dado BETWEENque no funciona para intervalos semiabiertos, siempre analizo detenidamente cualquier consulta de fecha / hora que lo use, ya que probablemente sea un error.

Tengo una ligera preferencia por BETWEENporque deja en claro instantáneamente al lector que está marcando un campo para un rango . Esto es especialmente cierto si tiene nombres de campo similares en su tabla.

Si, digamos, nuestra mesa tiene a transactiondatey a transitiondate, si leo

transactiondate between ...

Sé de inmediato que ambos extremos de la prueba están en contra de este campo.

Si leo

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

Tengo que tomarme un momento más para asegurarme de que los dos campos sean iguales.

Además, a medida que una consulta se edita con el tiempo, un programador descuidado podría separar los dos campos. He visto muchas consultas que dicen algo como

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

Si intentan esto con un BETWEEN, por supuesto, será un error de sintaxis y se solucionará de inmediato.

Creo que la única diferencia es la cantidad de azúcar sintáctica en cada consulta. BETWEEN es solo una forma hábil de decir exactamente lo mismo que en la segunda consulta.

Puede haber alguna diferencia específica de RDBMS que no conozco, pero realmente no lo creo.

Lógicamente no hay ninguna diferencia. En cuanto al rendimiento, por lo general, en la mayoría de los DBMS, no hay ninguna diferencia.

Vea esta excelente publicación de blog de Aaron Bertrand sobre por qué debería cambiar el formato de su cadena y cómo se manejan los valores límite en las consultas de rango de fechas.

Descargo de responsabilidad: todo lo que aparece a continuación es solo anecdótico y se extrae directamente de mi experiencia personal. Cualquiera que se sienta dispuesto a realizar un análisis más riguroso empíricamente puede llevarlo a cabo y votar en contra si yo lo hago. También soy consciente de que SQL es un lenguaje declarativo y se supone que no debes considerar CÓMO se procesa tu código cuando lo escribes, pero, como valoro mi tiempo, lo hago.

Hay infinitas declaraciones lógicamente equivalentes, pero consideraré tres (más o menos).

Caso 1: dos comparaciones en un orden estándar (orden de evaluación fijo)

A> = MinBound Y A <= MaxBound

Caso 2: Azúcar sintáctico (el orden de evaluación no lo elige el autor)

ENTRE MinBound Y MaxBound

Caso 3: dos comparaciones en un orden educado (orden de evaluación elegido en el momento de la escritura)

A> = MinBound Y A <= MaxBound

O

A <= MaxBound Y A> = MinBound

En mi experiencia, el Caso 1 y el Caso 2 no tienen diferencias consistentes o notables en el rendimiento, ya que ignoran el conjunto de datos.

Sin embargo, el Caso 3 puede mejorar considerablemente los tiempos de ejecución. En concreto, si se trabaja con un gran conjunto de datos y pasar a tener algún conocimiento heurístico acerca de si una es más probable que sea mayor que el MaxBound o menor que el MinBound puede mejorar notablemente los tiempos de ejecución mediante el uso de la caja 3 y ordenar las comparaciones en consecuencia.

Un caso de uso que tengo es consultar un gran conjunto de datos históricos con fechas no indexadas para registros dentro de un intervalo específico. Al escribir la consulta, tendré una buena idea de si existen más datos ANTES del intervalo especificado o DESPUÉS del intervalo especificado y puedo ordenar mis comparaciones en consecuencia. He tenido tiempos de ejecución reducidos a la mitad dependiendo del tamaño del conjunto de datos, la complejidad de la consulta y la cantidad de registros filtrados por la primera comparación.

En este escenario col BETWEEN ... AND ...y col <= ... and col >= ...son equivalentes.

El estándar SQL define también el predicado T461 Symmetric BETWEEN :

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

Transact-SQL no admite esta función.

BETWEENrequiere que los valores estén ordenados. Por ejemplo:

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

<=>

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

Por otra parte:

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

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

Funciona exactamente como lo normal BETWEENpero después de ordenar los valores de comparación.

db <> demostración de violín