Здравствуйте такой вопрос.
В хранимую процедуру поступает параметр @parResolutionDateOper который может принимать значения 
1. Equals
2. Not Equals 
3. Is Before
4. Is After  
 
На основе этого параметра в SQL должно быть использовано одно из условии
1. WHERE data = @parResolutionDateStart 
2. WHERE data <> @parResolutionDateStart 
3. WHERE data < @parResolutionDateStart 
4. WHERE data > @parResolutionDateStart 

как это красиво реализовать? Сейчас сделал так



Есть какой ни будь более красивый способ?

Это сообщение отредактировал(а) KuMa1104 - 16.3.2012, 16:33

CASE

Написать четыре разных запроса.

Для вас это может оказаться удивительно, но в общем случае это так. Для всех четырех типов запросов может быть построен разный план. Три их них могут оказаться достаточно эффективными. Один, для отбора по неравенству, эффективным быть не может в принципе. Для одного же запроса на все четыре случая план будет выстроен одинаково не эффективный для каждого из случаев, а потому запросы стоит объединять в один только в частном случае, когда надежд построить эффективный план для трех других запросов - нет или же производительность не имеет значения.

Добавлено через 11 минут и 9 секунд
Можно, кстати написать не четыре, а один запрос, объединив четыре по union all.   


Это сообщение отредактировал(а) Zloxa - 16.3.2012, 19:02

Спасибо за ваши ответы.

В SQL нельзя написать конструкцию вида

поэтому это здесь не применимо. Если знаете какой то другой способ как это сделать то будьте добры расскажите будет интересно посмотреть.



к сожалению не предоставляется возможным так как помимо @parResolutionDateOper в запросах присутствует несколько подобных фильтров например (@parExceptionDateOper, @parItemDate ...) а значит число запросов будет огромно. 4*4*4


Если не сложно поясните как это выглядит и дает ли какие то преимущества. 


 Можете посоветовать какую ни будь литературу про то как строить эффективные планы запросов. Опыт в написании и оптимизации запросов не богат, так что почитаю с интересом)))




Это сообщение отредактировал(а) KuMa1104 - 17.3.2012, 19:35

Тогда составлять текст запроса динамически 
Но динамика это плохо. Но лучше чем один запрос на все случаи жизни





Оптимизатору будет проще построить эффективный план такого запроса. Трансформировать исходный запрос через or к этому виду, оптимизатор, мне думается, на современном этапе развития, самостоятельно врядли сможет.

В случае если ResolutionDate  индексирован, первый подзапрос сможет использовать этот индекс, второй - нет. В случае, если условия записаны через OR оптимизатор, наверняка выберет полное сканирование таблицы. В случае с union, наверняка первый подзапрос будет искать по индексу, второй фуллсканить. Однако в случае если @parResolutionDateOper != 'Does Not Equal', хоть второй подзапрос никуда не делся из плана, выполняться он, наверняка, не станет. Получается запрос через юнинон будет фуллсканить только когда это действительно надо, а не всякий раз.

Именно так они сейчас и устроены. Это очень не удобно сопровождать и отлаживать, а кроме того как я понимаю Exec(@SQL) не кеширует запрос поэтому это работает медленнее.



Спасибо за объяснение, не знал такого!