В общем есть сабж.
Хранимки выбирают данные из 3-х таблиц.
И в каждой из них Селект отличается только строкой where?


Можно ли как-то сделать так(с помощью IF?) , чтобы у меня біл один
селект с тремя разніми, подставляеміми по условиям where?
Т.е. всего будет одна хранимка с передаваемім флагом, какой where нужно
візівать.
Views не предлагать.

Среда MS SQL 2000

Здравствуйте, alexdp, Вы писали:

A>Можно ли как-то сделать так(с помощью IF?) , чтобы у меня біл один
A>селект с тремя разніми, подставляеміми по условиям where?
A>Т.е. всего будет одна хранимка с передаваемім флагом, какой where нужно
A>візівать.

where ( flag=1 and (...) )
   or ( flag=2 and (...) )
   or ...

wildwind wrote:

>
> Здравствуйте, alexdp, Вы писали:
>
> A>Можно ли как-то сделать так(с помощью IF?) , чтобы у меня біл один
> A>селект с тремя разніми, подставляеміми по условиям where?
> A>Т.е. всего будет одна хранимка с передаваемім флагом, какой where нужно
> A>візівать.
>
> where ( flag=1 and (...) )
> or ( flag=2 and (...) )
> or ...

Вау, спасибо, буду пробовать.

Здравствуйте, alexdp, Вы писали:


A>Вау, спасибо, буду пробовать.

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

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, alexdp, Вы писали:

A>>Можно ли как-то сделать так(с помощью IF?) , чтобы у меня біл один
A>>селект с тремя разніми, подставляеміми по условиям where?
A>>Т.е. всего будет одна хранимка с передаваемім флагом, какой where нужно
A>>візівать.

Можно, например, используя временную таблицу если во всех трех where есть пара
тройка схожих условий, тогда из 10 млн. записей выбирается несколько десятков
тысяч во временную таблицу, после чего над таблицей проходят три select.

W>

W>where ( flag=1 and (...) )
W>   or ( flag=2 and (...) )
W>   or ...
W>

Подобных методов лучше избегать, т.к. почти гарантированно неоптимальный execution
plan и неиспользование индексов

Здравствуйте, protected, Вы писали:

P>Подобных методов лучше избегать, т.к. почти гарантированно неоптимальный execution
P>plan и неиспользование индексов
Почему? Разве оптимизатор не сообразит, что раз @flag=1, то другие условия можно опустить?

А такой вариант

      select * from t where @flag=1 and ...
union select * from t where @flag=2 and ...
union ...

Здравствуйте, wildwind, Вы писали:

W>Почему? Разве оптимизатор не сообразит, что раз @flag=1, то другие условия можно опустить?

Использование OR вызывает у оптимизатора "вопросы остающиеся без ответов"

W>

W>      select * from t where @flag=1 and ...
W>union select * from t where @flag=2 and ...
W>union ...
W>

Да, такой вариант вполне возможен.

protected wrote:

> A>>Можно ли как-то сделать так(с помощью IF?) , чтобы у меня біл один
> A>>селект с тремя разніми, подставляеміми по условиям where?
> A>>Т.е. всего будет одна хранимка с передаваемім флагом, какой where нужно
> A>>візівать.
>
> Можно, например, используя временную таблицу если во всех трех where
> есть пара
> тройка схожих условий, тогда из 10 млн. записей выбирается несколько
> десятков
> тысяч во временную таблицу, после чего над таблицей проходят три select.

У меня общих условий нет.
Там только 4-5 условий:
1) вібрать все записи, т.е. "вєрє" нет
2) вібрать все записи конкретного клиента
3) вібрать конкретную уникальную запись по двум АйДи
4) вібрать все записи по одному ИД
5) вібрать все записи по второму ИД

> W>where ( flag=1 and (...) )
> W> or ( flag=2 and (...) )
> W> or ...
> W>
>
>
>
> Подобных методов лучше избегать, т.к. почти гарантированно неоптимальный
> execution
> plan и неиспользование индексов


Про екзекюшн план ничего не скажу, но почему не будут использоваться
индексі?

Т.е. получается придется все оставить так как есть?

А если использовать Вьюз, проблема " execution
> plan и неиспользование индексов" уйдет?

protected wrote:

> Здравствуйте, wildwind, Вы писали:
>
> W>Почему? Разве оптимизатор не сообразит, что раз @flag=1, то другие
> условия можно опустить?
>
> Использование OR вызывает у оптимизатора "вопросы остающиеся без ответов"
>
> W>
>
> W> select * from t where @flag=1 and ...
> W>union select * from t where @flag=2 and ...
> W>union ...
> W>

В конкретном моем случае такой вариант не подойдет, бо вместо звездочки
у меня будет стоять 5-15 полей, которые нужно выбрать.

Да и при таких условиях можно использовать простой ИФ для проверки
условия, а уже в теле каждого ИФ пускать Селект.

Здравствуйте, alexdp, Вы писали:

A>В общем есть сабж.
A>Хранимки выбирают данные из 3-х таблиц.
A>И в каждой из них Селект отличается только строкой where?


A>Можно ли как-то сделать так(с помощью IF?) , чтобы у меня біл один
A>селект с тремя разніми, подставляеміми по условиям where?
A>Т.е. всего будет одна хранимка с передаваемім флагом, какой where нужно
A>візівать.
A>Views не предлагать.

A>Среда MS SQL 2000

А почему бы не использовать вами же предложенный вариант, IMHO наиболее рационально с точки зрения оптимизатора запросов.

create procedure getdata
    @flag int
as
    if (@flag = 1)
        select property, value from properties where property='100'
    else
        select property, value from properties where value in (3, 4)
GO

A>У меня общих условий нет.
A>Там только 4-5 условий:
A>1) вібрать все записи, т.е. "вєрє" нет
A>2) вібрать все записи конкретного клиента
A>3) вібрать конкретную уникальную запись по двум АйДи
A>4) вібрать все записи по одному ИД
A>5) вібрать все записи по второму ИД

Тогда лучше делать, как уже говорили, используя IF и передавать битпам-переменную:

IF ( (@FLAG AND 1) = 1)
     SELECT ...

IF ( (@FLAG AND 2) = 2)
     SELECT ...

Хотя я бы с точки зрения масштабируемости, назначения прав и понятности проекта оставил
бы несколько процедур. Но это уже вопросы религии

Здравствуйте, Alexey Frolov, Вы писали:

A>>Можно ли как-то сделать так(с помощью IF?) , чтобы у меня біл один
A>>селект

Ну и вдогонку. Если нужен именно один селект, то в хранимых процедурах должна быть возможность написать sql-запрос в виде текста и затем исполнить его, что-то вроде executeSQL("select * ..."). К сожалению не могу сходу сказать как это будет выглядеть точно, но где-то я такое видел

Здравствуйте, protected, Вы писали:


P>Хотя я бы с точки зрения масштабируемости, назначения прав и понятности проекта оставил
P>бы несколько процедур. Но это уже вопросы религии

Я бы прислушался к этому мнению. IMHO наиболее правильное, красивое и верное решение

Alexey Frolov wrote:

> Здравствуйте, Alexey Frolov, Вы писали:
>
> A>>Можно ли как-то сделать так(с помощью IF?) , чтобы у меня біл один
> A>>селект
>
> Ну и вдогонку. Если нужен именно один селект, то в хранимых процедурах
> должна быть возможность написать sql-запрос в виде текста и затем
> исполнить его, что-то вроде executeSQL("select * ..."). К сожалению не
> могу сходу сказать как это будет выглядеть точно, но где-то я такое видел

Да, такая возможность похоже есть, но боюсь там та же проблема будет
с оптимизацией и индексами.

Видать придется оставить как есть .
Просто с одним селектом в случае изменения полей таблиці придется
править однин селект в одной процедуре за один раз.
А так пять раз и обязательно где-нибудь ошибешься.

Ну и время написания процедур уменьшается, коенчно же.

Alexey Frolov wrote:
>

>
> Здравствуйте, protected, Вы писали:
>
>
> P>Хотя я бы с точки зрения масштабируемости, назначения прав и
> понятности проекта оставил
> P>бы несколько процедур. Но это уже вопросы религии

С назначением прав абсолютно согласен, а вот насчет
масштабируемости не понял. Да и понятность тоже, вроде как с одним
селектом повішается.

Да, я так понял должен быть еще один способ, вряд ли лучше чем
остальніе, но как вариант...
Вынести селект в отдельную процедуру и обрабатывать результаты ее вызова.

>
> Я бы прислушался к этому мнению. IMHO наиболее правильное, красивое и
> верное решение


Ну, значит прислушаюсь .
Но варианты довольно интересные.

Здравствуйте, alexdp, Вы писали:

A>Да, такая возможность похоже есть, но боюсь там та же проблема будет
A>с оптимизацией и индексами.

Не должно быть там проблем с оптимизацией и индексами. Вы наверное не совсем разобрались откуда такая проблема взялась.
Вот к примеру оптимизатор видит запрос

select name, age from people where name='Tom'

если в базе существует индекс по полю name таблицы people, скорее всего оптимизатор им воспользуется,
а если он получит запрос типа

select name, age from people where (@flag=1 and name='Tom') or (@flag=2 and age=30)

вот здесь не факт что оптимизатор сможет воспользоваться индексами (что 100% не воспользуется утверждать не стану) все зависит от того насколько умный оптимизатор. Здесь ему довольно сложно определить какой индекс использовать и использовать ли вообще, тем более мне кажется что реальное условие немного посложнее нежели age=30.

Кстати, совершенно не важно каким образом придет этот запрос. Будь то select... или execute('select ...')

A>Просто с одним селектом в случае изменения полей таблиці придется
A>править однин селект в одной процедуре за один раз.
A>А так пять раз и обязательно где-нибудь ошибешься.

A>Ну и время написания процедур уменьшается, коенчно же.

Согласен, проехали.

AF>Кстати, совершенно не важно каким образом придет этот запрос. Будь то select... или execute('select ...')
Зато в контексте безопасности результаты ой как могут отличаться.