Examinemos estas dos declaraciones:
IF (CONDITION 1) OR (CONDITION 2)
...
IF (CONDITION 3) AND (CONDITION 4)
...
Si CONDITION 1
es así TRUE
, ¿ CONDITION 2
será verificado?
Si CONDITION 3
es así FALSE
, ¿ CONDITION 4
será verificado?
¿Qué pasa con las condiciones en WHERE
: el motor de SQL Server optimiza todas las condiciones en una WHERE
cláusula? ¿Deberían los programadores colocar las condiciones en el orden correcto para asegurarse de que el optimizador de SQL Server lo resuelva de la manera correcta ?
ADICIONAL:
Gracias a Jack por el enlace, sorpresa del código t-sql:
IF 1/0 = 1 OR 1 = 1
SELECT 'True' AS result
ELSE
SELECT 'False' AS result
IF 1/0 = 1 AND 1 = 0
SELECT 'True' AS result
ELSE
SELECT 'False' AS result
No hay una excepción Divide por cero en este caso.
CONCLUSIÓN:
Si C ++ / C # / VB tiene un cortocircuito, ¿por qué SQL Server no puede tenerlo?
Para responder realmente a esto, echemos un vistazo a cómo ambos trabajan con condiciones. C ++ / C # / VB tienen cortocircuito definido en las especificaciones del lenguaje para acelerar la ejecución del código. ¿Por qué molestarse en evaluar las condiciones N O cuando la primera ya es verdadera o las condiciones M AND cuando la primera ya es falsa?
Como desarrolladores, debemos ser conscientes de que SQL Server funciona de manera diferente. Es un sistema basado en costos. Para obtener el plan de ejecución óptimo para nuestra consulta, el procesador de consultas debe evaluar cada condición where y asignarle un costo. Estos costos se evalúan en su conjunto para formar un umbral que debe ser inferior al umbral definido que SQL Server tiene para un buen plan. Si el costo es más bajo que el umbral definido, se usa el plan, si no, todo el proceso se repite nuevamente con una combinación diferente de costos de condición. El costo aquí es un escaneo o una búsqueda o una combinación de fusión o una combinación hash, etc. ... Debido a esto, el cortocircuito como está disponible en C ++ / C # / VB simplemente no es posible. Puede pensar que forzar el uso del índice en una columna cuenta como cortocircuito, pero no es así. Solo fuerza el uso de ese índice y con eso acorta la lista de posibles planes de ejecución. El sistema todavía está basado en costos.
Como desarrollador, debe tener en cuenta que SQL Server no hace un cortocircuito como se hace en otros lenguajes de programación y no hay nada que pueda hacer para forzarlo.