Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > MS SQL Server > Различные where в зависимости от параметра.

Автор: KuMa1104 16.3.2012, 16:31

Здравствуйте такой вопрос. В хранимую процедуру поступает параметр @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  как это красиво реализовать? Сейчас сделал так Код        (@parResolutionDateOper = 'Equals' AND ResolutionDate = @parResolutionDateStart )     OR     (@parResolutionDateOper = 'Does Not Equal' AND ResolutionDate <> @parResolutionDateStart)     OR     ......................... аналогично Есть какой ни будь более красивый способ?

Автор: Akina 16.3.2012, 17:24

CASE

Автор: Zloxa 16.3.2012, 18:56

Цитата(KuMa1104 @  16.3.2012,  17:31 ) Есть какой ни будь более красивый способ? Написать четыре разных запроса. Для вас это может оказаться удивительно, но в общем случае это так. Для всех четырех типов запросов может быть построен разный план. Три их них могут оказаться достаточно эффективными. Один, для отбора по неравенству, эффективным быть не может в принципе. Для одного же запроса на все четыре случая план будет выстроен одинаково не эффективный для каждого из случаев, а потому запросы стоит объединять в один только в частном случае, когда надежд построить эффективный план для трех других запросов - нет или же производительность не имеет значения. Добавлено через 11 минут и 9 секунд Можно, кстати написать не четыре, а один запрос, объединив четыре по union all.

Автор: KuMa1104 17.3.2012, 19:33

Спасибо за ваши ответы. Цитата(Akina @  16.3.2012,  17:24 ) CASE  В SQL нельзя написать конструкцию вида Код Select * from DT where Case  @parResolutionDateOper      WHEN 'Equals' THEN DT.ResolutionDate = @parResolutionDateStart      WHEN 'Does Not Equal'  THEN DT.ResolutionDate <> @parResolutionDateStart  поэтому это здесь не применимо. Если знаете какой то другой способ как это сделать то будьте добры расскажите будет интересно посмотреть. Цитата(Zloxa @  16.3.2012,  18:56 ) Написать четыре разных запроса. к сожалению не предоставляется возможным так как помимо @parResolutionDateOper в запросах присутствует несколько подобных фильтров например (@parExceptionDateOper, @parItemDate ...) а значит число запросов будет огромно. 4*4*4 Цитата(Zloxa @  16.3.2012,  18:56 ) Можно, кстати написать не четыре, а один запрос, объединив четыре по union all.    Если не сложно поясните как это выглядит и дает ли какие то преимущества.  Цитата(Zloxa @  16.3.2012,  18:56 ) Для всех четырех типов запросов может быть построен разный план. Три их них могут оказаться достаточно эффективными.  Можете посоветовать какую ни будь литературу про то как строить эффективные планы запросов. Опыт в написании и оптимизации запросов не богат, так что почитаю с интересом)))

Автор: Zloxa 17.3.2012, 23:14

Цитата(KuMa1104 @  17.3.2012,  20:33 ) к сожалению не предоставляется возможным так как помимо @parResolutionDateOper в запросах присутствует несколько подобных фильтров например (@parExceptionDateOper, @parItemDate ...) а значит число запросов будет огромно. 4*4*4 Тогда составлять текст запроса динамически  Но динамика это плохо. Но лучше чем один запрос на все случаи жизни Цитата(KuMa1104 @  17.3.2012,  20:33 ) Если не сложно поясните как это выглядит  Код Select * from DT where @parResolutionDateOper = 'Equals' and DT.ResolutionDate = @parResolutionDateStart  union all Select * from DT where @parResolutionDateOper = 'Does Not Equal' and DT.ResolutionDate <> @parResolutionDateStart  Цитата(KuMa1104 @  17.3.2012,  20:33 ) и дает ли какие то преимущества.  Оптимизатору будет проще построить эффективный план такого запроса. Трансформировать исходный запрос через or к этому виду, оптимизатор, мне думается, на современном этапе развития, самостоятельно врядли сможет. В случае если ResolutionDate  индексирован, первый подзапрос сможет использовать этот индекс, второй - нет. В случае, если условия записаны через OR оптимизатор, наверняка выберет полное сканирование таблицы. В случае с union, наверняка первый подзапрос будет искать по индексу, второй фуллсканить. Однако в случае если @parResolutionDateOper != 'Does Not Equal', хоть второй подзапрос никуда не делся из плана, выполняться он, наверняка, не станет. Получается запрос через юнинон будет фуллсканить только когда это действительно надо, а не всякий раз.

Автор: KuMa1104 18.3.2012, 12:22

Цитата(Zloxa @  17.3.2012,  23:14 ) Тогда составлять текст запроса динамически Именно так они сейчас и устроены. Это очень не удобно сопровождать и отлаживать, а кроме того как я понимаю Exec(@SQL) не кеширует запрос поэтому это работает медленнее. Цитата(Zloxa @  17.3.2012,  23:14 ) В случае если ResolutionDate  индексирован, первый подзапрос сможет использовать этот индекс, второй - нет. В случае, если условия записаны через OR оптимизатор, наверняка выберет полное сканирование таблицы. В случае с union, наверняка первый подзапрос будет искать по индексу, второй фуллсканить. Однако в случае если @parResolutionDateOper != 'Does Not Equal', хоть второй подзапрос никуда не делся из плана, выполняться он, наверняка, не станет. Получается запрос через юнинон будет фуллсканить только когда это действительно надо, а не всякий раз.  Спасибо за объяснение, не знал такого!

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)