Создание динамического пользовательского запроса без ограничений по параметрам в SQL

Question

У меня есть страница asp.net, которая позволяет пользователю выполнять поиск в базе данных, создавая предложение where для включения в хранимую процедуру. Проблема заключается в том, что процедура должна учитывать неизвестное количество параметров для разных условий. Слишком упрощенный пример мог бы выглядеть примерно так:

SELECT [Column1] FROM [TableName] WHERE 1=1 
--Everything below user generated 
AND 
(
    ([Column2] = '1' AND [Column3] = '5' AND [Column4] = '9') OR 
    ([Column2] = '2' AND [Column3] = '6' AND [Column4] = '8') OR 
    ... 
    ([Column2] = '25' AND [Column3] = '3' AND [Column4] = '1') 
) 
AND [Column5] BETWEEN '10' AND '200' 

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

Answer 1

В первую очередь хранимая процедура является оптимизированным/контекстуализированным планом выполнения.

Вы хотите, чтобы у вас не было ограничений для ваших управляемых столбцов, операторов (=, LIKE, <, ...) и количества условий поиска (AND/OR). Это не сводится к плану выполнения.

И даже если у вас есть «легкое» ограничение, вам придется использовать множество параметров с условиями поиска, такими как ([ColumnX] IS NULL OR [ColumnX] = @parameterX) AND .... Это вызовет проблему с производительностью из-за параметра sniffing (more information here). И после оптимизации вы все равно не будете быстрее, чем простой Select, созданный из вашего приложения ASP.

Фактически использование динамического sql было бы лучшим решением, если вы все еще хотите использовать хранимую процедуру. Но вы все равно можете столкнуться с некоторыми результатами производительности, которых у вас не было бы в простом запросе (an example of performance problem).

Ответьте на свой вопрос здесь, забудьте о хранимой процедуре и используйте запрос.