Сохранение динамики из SQL при использовании спецификаций с хранимыми процедурами

Question

Спецификация, по сути, представляет собой текстовую строку, представляющую предложение "where", созданное конечным пользователем.

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

Что если мы передадим пользовательскую спецификацию (или строковый параметр) в скалярную функцию, которая вернула истину / ложь, которая выполнила спецификацию как динамический SQL или просто exec (@variable). Это может сказать нам, существуют ли эти записи. Мы могли бы добавить результат этой функции в наши продукты для копий where.

Это не позволит нам перекомпилировать скрипт копирования каждый раз, когда изменяются наши предложения where. Плюс это изолировало бы выбор продукта в одной функции.

Кто-нибудь когда-нибудь делал что-нибудь подобное или есть примеры? Что плохого может из этого получиться?

EDIT:

Это спецификация, которую я просто добавил в конец каждого оператора вставки / выбора:

and exists (
    select null as nothing
    from SameTableAsOutsideTable inside
    where inside.ID = outside.id and      -- Join operations to outside table

          inside.page in (6, 7) and       -- Criteria 1
          inside.dept in (7, 6, 2, 4)     -- Criteria 2
)

Было бы замечательно передать параметр в функцию, которая создает записи на основе пользовательских критериев, поэтому все вышеперечисленное может выглядеть примерно так:

and dbo.UserCriteria( @page="6,7", @dept="7,6,2,4")

Answer 1

Условия динамического поиска в T-SQL

При оптимизации SQL важно оптимизировать путь доступа к данным (т. Е. Использование индекса).Это превосходит повторное использование кода, удобство сопровождения, удобное форматирование и практически все остальные преимущества разработки, о которых вы только можете подумать.Это связано с тем, что неправильный путь доступа приведет к тому, что запрос будет выполняться в сотни раз медленнее, чем должен.Связанная статья очень хорошо суммирует все варианты, которые у вас есть, и ваша предполагаемая функция нигде не видна.Ваши варианты будут зависеть от динамического SQL или очень сложных статических запросов.Боюсь, что по этой теме нет бесплатного обеда.

Answer 2

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

Кроме того, почти всегда плохая идея позволять пользователям создавать предложения WHERE произвольной формы.Пользователи довольно хороши в поиске новых и инновационных способов остановить сервер.

Если вы, ваши пользователи или кто-либо другой в бизнесе не можете придумать какие-то конкретные требования к поиску, то, вероятно,кто-то не думает об этом достаточно усердно и не знает, чего он хочет.Вы можете иметь довольно универсальные возможности поиска, не позволяя пользователям полностью потерять систему.В качестве альтернативы, посмотрите на некоторые инструменты BI и рассмотрите возможность создания витрины данных, где они могут выполнять подобные поиски.

Answer 3

Если вы вынуждены использовать динамические запросы и у вас нет четких и предопределенных требований к поиску, настоятельно рекомендуется использовать sp_executesql вместо EXEC. Он предоставляет параметризованные запросы для предотвращения атак SQL Injection (в некоторой степени) и использует планы выполнения для повышения производительности. ( Подробнее )

Answer 4

Как насчет этого: вы создаете другую процедуру хранения (вместо функции) и передаете ей правильное условие.Основываясь на этом условии, он сбрасывает идентификаторы записей во временную таблицу.

Затем вы перемещаете процедуру, которая будет считывать идентификаторы из этой таблицы и выполнять необходимые действия?

Или вы можете создать пользовательскую функцию, котораявозвращает таблицу, которая является ничем иным, как идентификаторами записей, которые соответствуют вашим критериям (динамический)

Если я полностью выключен, то, пожалуйста, уточните меня.

Надеюсь, это поможет.