Составной Where со многими OR

имеется сложная комбинация условий в Where:
@x=... or @x=... or @x=... or @x=...
где переменная @x определяется снаружи SELECT, а в качетве троеточий указаны рассчитываемые выражения.

Я ведь не ошибаюсь, что для удовлетворения WHERE нужно ТОЛЬКО ПЕРВОЕ СЛЕВА удовлетворенное условие - тогда остальные выражения уже не будут рассчитываться вовсе, несмотря на то, что в SQL-плане включен ПОЛНЫЙ расчет.
(В языках высокого уровня можно добится и такой и противоположной техники расчета, например в IIF - расчитываются всегда ВСЕ части, независимо от того, что условие УЖЕ давно удовлетворено, а просто в IF - слева только до ПЕРВОГО удовлетворения условия.)

И вторая часть проблемы - одно из частей этого составного выражения выглядит примерно так
FreeText([xTab].[xValue],@x).
Собственно еще одна проблема в этом самом FreeText - при задании в него пустой строки - он падает с сообщением : Null or empty full-text predicate.
Поскольку длину поиска я ограничил 50-ю символами - ну не писать же мне перед этим Where пятьдесят раз экранирующее выражение @x=' ' or @x=' ' or @x=' ' or @x=' ' и так далее, а вот как убедится, что строка произвольной длины содержит ТОЛЬКО пробелы - уже перегрелся - сообразить никак не могу... Ну можно конечно какую-то функцию свою составить. Ну а как это сделать лучше, чтоб расчет условия до FreeText и не дошел?

vbnet2000

Ну а как это сделать лучше, чтоб расчет условия до FreeText и не дошел?

А то, что будет полный скан, Вас не пугает?

vbnet2000

а вот как убедится, что строка произвольной длины содержит ТОЛЬКО пробелы

LTRIM(RTRIM(@x)) = ''

LTRIM(RTRIM(@x)) = ''

Спасибо. С утра это совершенно очевидно.

А то, что будет полный скан, Вас не пугает?

Да, это крайне важно, понимаю. Но в этом Where есть еще штук пять условий в AND, внутри каждого и стоят условия OR. Они и должны ограничить полный скан. Просто в данной проблеме я был сосрдоточен на том, чтобы внутри каждого AND расчет отстановился на первом слева условии, ибо чем дальше вправо - тем тяжелее расчетные условия. Скажем второе-третье условия просчитываются за 2-3 секунды, а самое правое - 40 секунд.

vbnet2000

Скажем второе-третье условия просчитываются за 2-3 секунды, а самое правое - 40 секунд.

К Вас там еще, поди, и функции в условиях, с запросами внутри?

К Вас там еще, поди, и функции в условиях, с запросами внутри?

Попадаются кое-где. Но я расчитываю, что именно как только левое условие удовлетворено, дальше расчет останавливается и более правым условиям движок SQL и не перейдет (а не так как это происходит в IIF). Этой фишки СОВЕРШЕННО не видно на плане запроса, в котором конечно веса расчета приведены из прогноза ПОЛНОГО расчета всего выражения в Where.

Noskov

vbnet2000 а вот как убедится, что строка произвольной длины содержит ТОЛЬКО пробелы LTRIM(RTRIM(@x)) = ''

Одного TRIM-а(L или R) было бы достаточно :)

vbnet2000

К Вас там еще, поди, и функции в условиях, с запросами внутри? Попадаются кое-где. Но я расчитываю, что именно как только левое условие удовлетворено, дальше расчет останавливается и более правым условиям движок SQL и не перейдет (а не так как это происходит в IIF). Этой фишки СОВЕРШЕННО не видно на плане запроса, в котором конечно веса расчета приведены из прогноза ПОЛНОГО расчета всего выражения в Where.

Вобще-то оптимизатор сам решает какое условие имеет смысл проверять раньше и порядок проверки может быть не таким, как Вы напишите. Лично я бы не стал на это надеяться

Дык в том-то и все дело - почему я и переспросил - не ошибаюсь ли я насчет порядка расчета условий. Дело в том, что на тестах два раза вывалились результаты, которые не должны были бы вывалится. Они как-бы свидетельствуют об ином порядке расчета.
Но если порядок расчета выражений может быть произвольным - то как же тогда переписать вот все эти условия в Where внутри одного AND...
Не могу сообразить пока...

Я вообще-то ВСЕГДА опираюсь на то, что в SELECT левое выражение рассчитывается РАНЬШЕ чем правое, поэтому подумал - что и тут тот же принцип...Тем более, на 1000 прогонах, только дважды появились необьяснимые результаты по времени...