у меня запрос есть, типа select * from Table where Par1=1 and Par2 IN (1,2,3,....) Можно ли как-нибудь сделать параметризированный запрос, если число параметров в IN может быть любым?

Здравствуйте, Митрошин Александр, Вы писали:

МА>у меня запрос есть, типа select * from Table where Par1=1 and Par2 IN (1,2,3,....) Можно ли как-нибудь сделать параметризированный запрос, если число параметров в IN может быть любым?
увы, нет. Придется "собирать" запрос руками, т.е. вместо биндинга параметров конструировать строку.
Это можно сделать и на сервере, если он поддерживает динамическое исполнение.
Например, в MS SQL можно сделать процедуру, которая принимает в качестве одного из параметров строку разделенных запятыми констант. Внутри эта процедура строит тот самый селект и при помощи execute выполняет его.
Разницы, в общем-то, никакой — все равно запрос придется компилировать каждый раз. Известные мне сервера не умеют кэшировать планы для запросов такого типа.

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

S>Здравствуйте, Митрошин Александр, Вы писали:

S>увы, нет. Придется "собирать" запрос руками, т.е. вместо биндинга параметров конструировать строку.

Печально, печально...дело в том, что параметров может быть тысяча и две тысячи — тормозить же будет . А если таблицу подсовывать?Может, будет быстрее?

Здравствуйте, Митрошин Александр, Вы писали:

МА>Печально, печально...дело в том, что параметров может быть тысяча и две тысячи — тормозить же будет . А если таблицу подсовывать?Может, будет быстрее?
Гм. основные тормоза (скорее всего) будут при передаче запроса в сервер.
Да, для способа с использованием прямого перечисления в in () есть ограничение (MS SQL например ограничивает размер бвтча в 64к). Две тысячи целых констант гарантированно в него влезут...
Способ с использованием таблички гарантирует единообразную обработку списков любой длины. Но! Если в качестве параметров используются целые числа, то первый способ съест не более 11 байт на элемент, в то время как при втором придется N раз передать на сервер

insert into #t(a) values (xxxx);

или (если заранее подготовится)

exec add_param xxxx

Это существенно увеличит суммарный трафик и может негативно сказаться на производительности при наличии транзакций.

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

S>Здравствуйте, Митрошин Александр, Вы писали:

S>Способ с использованием таблички гарантирует единообразную обработку списков любой длины. Но! Если в качестве параметров используются целые числа, то первый способ съест не более 11 байт на элемент, в то время как при втором придется N раз передать на сервер
S>

S>insert into #t(a) values (xxxx);
S>

S>или (если заранее подготовится)
S>

S>exec add_param xxxx
S>

S>Это существенно увеличит суммарный трафик и может негативно сказаться на производительности при наличии транзакций.

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

select * from Table where Par1=1 and Par2 IN (select Par2 from table2 where ID=?)

Так быстрее будет?

Здравствуйте, Митрошин Александр, Вы писали:

МА>дело в том, что параметров может быть тысяча и две тысячи

А сервер какой? В Oracle (насчет 9i не знаю, но в 8.0 — точно) ограничение на число элементов в in() — 1000. Так что придется еще и union к этой конструкции соорудить. Может, действительно, во временную таблицу подготавливать, а потом — inner join? Тогда в том же Oracle можно воспользоваться array insert-ами и существенно сэкономить на сетевом трафике.