Проверьте, существует ли таблица в SQL Server

Ограничения оператора in () являются корнем всего зла.

Он работает для тривиальных случаев, и вы можете расширить его с помощью «автоматической генерации подготовленного заявления», однако он всегда имеет свои пределов.

• , если вы создаете оператор с переменным числом параметров, который будет обрабатывать служебные данные SQL для каждого вызова
• на многих платформах, количество параметров of () ограничены
• на всех платформах, общий размер текста SQL ограничен, что делает невозможным отправку 2000 заполнителей для параметров in
• , отправляющих переменные связывания 1000- 10k невозможно, так как драйвер JDBC имеет свои ограничения

Подход in () может быть достаточно хорош для некоторых случаев, но не для защиты от ракеты:)

Ракетно-защитное решение состоит в том, чтобы передать произвольное количество параметров в отдельный вызов (например, путем передачи клока параметров), а затем иметь представление (или любой другой способ) для представления их в SQL и использовать в вашем месте критерии.

Вариант грубой силы здесь http://tkyte.blogspot.hu/2006/06/varying-in-lists.html

Однако, если вы можете использовать PL / SQL, этот беспорядок может стать довольно опрятным.

function getCustomers(in_customerIdList clob) return sys_refcursor is 
begin
    aux_in_list.parse(in_customerIdList);
    open res for
        select * 
        from   customer c,
               in_list v
        where  c.customer_id=v.token;
    return res;
end;

Затем вы можете передать произвольное количество идентификаторов клиентов, разделенных запятыми, в параметре и:

• не будет получать задержку синтаксического анализа, так как SQL для select является стабильным
• Отсутствие сложностей с конвейерными функциями - это всего лишь один запрос
• , когда SQL использует простое соединение, вместо этого из оператора IN, который довольно быстр
• в конце концов, это хорошее эмпирическое правило not , попадающее в базу данных с любым простым выбором или DML, поскольку это Oracle, который предлагает lightyears больше, чем MySQL или аналогичные простые двигатели баз данных. PL / SQL позволяет скрыть модель хранилища от вашей модели домена приложения эффективным способом.

Трюк здесь:

• нам нужен звонок который принимает длинную строку и хранит где-нибудь, где сеанс db может получить к ней доступ (например, простая переменная пакета или dbms_session.set_context)
• , тогда нам нужно представление, которое может анализировать это на строки
• , а затем у вас есть представление, которое содержит идентификаторы, которые вы запрашиваете, поэтому все, что вам нужно, - это простое соединение с запрошенной таблицей.

Вид выглядит так:

create or replace view in_list
as
select
    trim( substr (txt,
          instr (txt, ',', 1, level  ) + 1,
          instr (txt, ',', 1, level+1)
             - instr (txt, ',', 1, level) -1 ) ) as token
    from (select ','||aux_in_list.getpayload||',' txt from dual)
connect by level <= length(aux_in_list.getpayload)-length(replace(aux_in_list.getpayload,',',''))+1

, где aux_in_list.getpayload ссылается на исходную строку ввода.

---

Возможным подходом было бы передать массивы pl / sql (поддерживаемые только Oracle), однако вы можете ' t использовать их в чистом SQL, поэтому шаг преобразования всегда необходим. Преобразование не может быть выполнено в SQL, поэтому, в конце концов, самым эффективным решением является передача clob со всеми параметрами в строке и преобразование его в представление.