Pregunta

En SQL Server 2000 y 2005:

  • ¿cuál es la diferencia entre estas dos cláusulas WHERE ?
  • ¿cuál debo 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: faltaba originalmente la segunda fecha de evento, por lo que la consulta era sintácticamente incorrecta)

¿Fue útil?

Solución

Son idénticos: ENTRE es una abreviatura para la sintaxis más larga en la pregunta.

Utilice una sintaxis más larga alternativa donde ENTRE no funciona, por ejemplo, 

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

(Nota < en lugar de < = en segunda condición)

Otros consejos

Son lo mismo.

Una cosa de la que hay que tener cuidado 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

( coincidiría con < = 20/10/2009 00: 00: 00.000 )

Aunque BETWEEN es 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 ENTRE first AND last , pero en la práctica esto suele ser más fácil de escribir dt > = first AND dt < ; next-first (que también resuelve el problema del tiempo parcial), ya que determinar last generalmente 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, ENTRE bajo y alto ).

Normalmente, no hay diferencia: la palabra clave BETWEEN no es compatible con todas las plataformas RDBMS, pero si lo es, las dos consultas deberían 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.

Según lo mencionado por @marc_s, @Cloud, et al. son básicamente lo mismo para un rango cerrado.

Pero cualquier valor de tiempo fraccional puede causar problemas con un rango cerrado (mayor o igual y menor o igual ) en oposición a un rango medio abierto (mayor o igual y menor que ) con un valor final después de el último instante posible.

Para evitar que la consulta se vuelva a escribir como: 

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

Dado que ENTRE no funciona durante intervalos medio abiertos, siempre analizo detenidamente cualquier consulta de fecha / hora que lo use, ya que probablemente sea un error.

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

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

Tengo una ligera preferencia por ENTRE porque deja claro al instante al lector que está comprobando un campo para un rango . Esto es especialmente cierto si tiene nombres de campo similares en su tabla.

Si, por ejemplo, nuestra tabla tiene una transaccióndate y una 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 extra 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 ENTRE , por supuesto, será un error de sintaxis y se solucionará rápidamente.

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

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

Descargo de responsabilidad: Todo lo siguiente es solo anecdótico y extraído directamente de mi experiencia personal. Cualquier persona que tenga ganas de realizar un análisis empíricamente más riguroso es bienvenido a llevarlo a cabo y rechazar el voto si lo hago. También sé 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 (ish).

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

  

A > = MinBound AND A < = MaxBound

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

  

UN ENTRE MinBound Y MaxBound

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

  

A > = MinBound AND A > = MaxBound

O

  

A > = MaxBound AND A > = MinBound

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

Sin embargo, el Caso 3 puede mejorar enormemente los tiempos de ejecución. Específicamente, si está trabajando con un gran conjunto de datos y tiene algún conocimiento heurístico sobre si A es más probable que sea mayor que el MaxBound o menor que el < strong> MinBound puede mejorar notablemente los tiempos de ejecución utilizando el Caso 3 y ordenando 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. Los tiempos de ejecución se redujeron 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.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top