No sé SQL Server, así que no puedo hablar de eso.
Dada una expresión a L b por algún operador lógico L, no hay ninguna garantía de que a serán evaluados antes o después de b o incluso que tanto a y b serán evaluados:
Expression Evaluation Rules
El El orden de evaluación de las subexpresiones no está definido. En particular, las entradas de un operador o función no necesariamente se evalúan de izquierda a derecha o en cualquier otro orden fijo.
Además, si el resultado de una expresión puede determinarse evaluando solo algunas partes de él, entonces otras subexpresiones podrían no evaluarse en absoluto.
[...]
Tenga en cuenta que esto no es lo mismo que el "cortocircuito" de izquierda a derecha de los operadores booleanos que se encuentra en algunos lenguajes de programación.
Como consecuencia, no es prudente utilizar funciones con efectos secundarios como parte de expresiones complejas. Es particularmente peligroso confiar en los efectos secundarios o la orden de evaluación en las cláusulas WHERE y HAVING, ya que esas cláusulas se reprocesan ampliamente como parte del desarrollo de un plan de ejecución.
Por lo que una expresión de la forma:
the_column IS NULL OR the_column < 10
se refiere, no hay nada de qué preocuparse ya que es NULL < nNULL para todos n, incluso NULL < NULL evalúa a NULL; Por otra parte, NULL no es cierto por lo
null is null or null < 10
es sólo una manera complicada de decir true or null y eso es true independientemente de la sub-expresión se evalúa primero.
Todo el "use a CASE" suena principalmente como el culto de carga SQL para mí. Sin embargo, como la mayoría del culto a la carga, hay un grano, una verdad enterrada debajo de la carga; justo debajo de mi primer extracto del manual de PostgreSQL, se dará cuenta de esto:
Cuando es esencial para forzar el orden de evaluación, una CASE construcción (véase la Sección 9.16) se puede utilizar. Por ejemplo, esta es una manera poco fiable de tratar de evitar la división por cero en un WHERE cláusula:
SELECT ... WHERE x > 0 AND y/x > 1.5;
Pero esto es seguro:
SELECT ... WHERE CASE WHEN x > 0 THEN y/x > 1.5 ELSE false END;
lo tanto, si usted necesita para protegerse de una condición que generará una excepción u otros efectos secundarios, entonces debe usar un CASE para controlar el orden de evaluación como CASE es evaluated in order:
Cada condición es una expresión que arroja un resultado de boolean. Si el resultado de la condición es verdadero, el valor de la expresión CASE es resultado que sigue la condición y el resto de la expresión CASE no se procesa. Si el resultado de la condición no es verdadero, las siguientes cláusulas WHEN se examinan de la misma manera.
Así que dado esto:
case when A then Ra
when B then Rb
when C then Rc
...
A se garantiza que sea evaluado antes B, B antes C, etc., y la evaluación se detiene tan pronto como una de las condiciones se evalúa como un valor verdadero.
En resumen, un CASE cortocircuitos ni peros ni ANDOR cortocircuito por lo que sólo necesitan utilizar un CASE cuando es necesario para proteger contra los efectos secundarios.
Quizás estaban hablando de Y? Como nulo Y cualquier cosa es nula, a menudo es necesario unir o un caso donde las expresiones pueden contener términos nulos. –