скобки не спасут. Дело в том, что неявная булева логика в условиях с NULL не двузначна, а 3-х-значна. Существует там такое условное значение UNKNOWN, наряду с условными TRUE и FALSE. Этот UNKNOWN возникает при сравнении какого-то значения с NULL'ом. В общем-то, ничего страшного, т.к. когда этот UNKNOWN возникает где-то при вычислении в условияи WHERE, он, в общем-то, очень похож на FALSE. И ведет себя "хорошо", если его OR'ить или AND'ить с другими логическими выражениями в WHERE. Но есть 1 закавыка: при применении NOT к UNKNOWN'у получается опять же UNKNOWN. Это как раз и будет в том примере, если влепить туда NOT. И это исказит всю логику. Поэтому я и написал, что нужно быть очень осторожным при дальнейших модификациях этого кода. Впрочем, это все уже дебри.
А вообще - длинные вычисления условий в SQL - мрак. если совсем
критично, то наверное легче сделать временную табличку и пользовать
стандартный Join
ну-у-у... it depends... порой и можно более-менее серьезные вещи вылепить. Но... скажем, для репортинга - до поры до времени можно обходиться вьюхами, но потом, когда возникает потребность в сложных вычислениях по всяким бл#%ским квартальным отчетностям, то тут уже действительно надо строгать серьезные хранимые процедуры. А там уже и временные таблички, и табличные переменные, и прочий арсенал.
--------------
Авиатор х#ев