Я не знаю SQL Server, поэтому не могу говорить об этом.
Учитывая выражение a L b для некоторого логического оператора L, нет гарантии, что a будет оцениваться до или после b или даже что и a, и b будут оцениваться:
Правила оценки выражений
Порядок вычисления подвыражений не определен. В частности, входные данные оператора или функции не обязательно оцениваются слева направо или в любом другом фиксированном порядке.
Кроме того, если результат выражения можно определить, оценивая только некоторые его части, то другие подвыражения могут вообще не оцениваться.
[...]
Обратите внимание, что это не то же самое, что «короткое замыкание» логических операторов слева направо, встречающееся в некоторых языках программирования.
Как следствие, неразумно использовать функции с побочными эффектами как часть сложных выражений. Особенно опасно полагаться на побочные эффекты или порядок оценки в предложениях WHERE и HAVING, поскольку эти пункты интенсивно обрабатываются в рамках разработки плана выполнения.
Что касается выражения вида:
the_column IS NULL OR the_column < 10
обеспокоен тем, что беспокоиться не о чем, поскольку NULL < n равно NULL для всех n, даже NULL < NULL равно NULL; Более того, NULL не соответствует действительности, поэтому
null is null or null < 10
это просто сложный способ сказать true or null, и это true независимо от того, какое подвыражение вычисляется первым.
Мне кажется, что «использование СЛУЧАЯ» звучит в основном как культ груза SQL. Однако, как и большинство грузовых культов, есть ядро истины, похороненной под грузом; чуть ниже моего первого отрывка из руководства PostgreSQL вы найдете это:
Когда необходимо форсировать порядок оценки, можно использовать конструкцию CASE (см. Раздел 9.16). Например, это ненадежный способ избежать деления на ноль в предложении WHERE:
SELECT ... WHERE x > 0 AND y/x > 1.5;
Но это безопасно:
SELECT ... WHERE CASE WHEN x > 0 THEN y/x > 1.5 ELSE false END;
Итак, если вам нужно защититься от состояния, которое вызовет исключение или будет иметь другие побочные эффекты, тогда вам следует использовать CASE для управления порядком оценки, поскольку CASE равно , вычисляемому в порядке
Каждое условие является выражением, которое возвращает boolean результат. Если результат условия истинен, значением выражения CASE является результат , следующий за условием, а остальная часть выражения CASE не обрабатывается. Если результат условия неверен, любые последующие предложения WHEN проверяются таким же образом.
Итак, учитывая это:
case when A then Ra
when B then Rb
when C then Rc
...
A гарантированно оценивается до B, B до C и т. Д., И оценка останавливается, как только одно из условий оценивается как истинное значение.
В итоге, CASE короткое замыкание не вызывает ни AND, ни OR короткое замыкание, поэтому вам нужно использовать CASE только тогда, когда вам нужно защитить от побочных эффектов.