Есть идея дать пользователю возможность создавать свои фильтры по некоторым вычисляемым параметрам.

Как в почтовой программе:
"если отправитель письма такой-то и тема содержит вот это,
то положить письмо в такую-то папку."

Прикинул - у меня получилось 12 таблиц для описания конструктора фильтров.

И возник вопрос - как лучше обрабатывать логику,
которую накликал пользователь:
Генерить финальный SQL на клиенте или на сервере процедурой,
и подставлять-ли в него уже вычисленные значения или ставить имена полей таблиц?

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

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

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

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

-2-,
Обеими руками "за",
если бы не уголовная ответстенность в случае, если в результате такого решения "что-то пойдет не так".
Все слишком серьезно в этот раз.

Так, продолжаю размышлять вслух (уж извините что отвлекаю).

Скорее всего, генерить SQL на клиенте не правильно:
1 - так теряется возможность использовать настроенные пользователем фильтры в джобах. (когда клиент получает результат автоматических проверок по своим фильтрам - например, по почте.)
2 - вопрос безопасности: доверия тому, что прилетело для выполнения в сервер от клиента - все-таки меньше, чем тому, что сгенерирует сервер по заранее известным правилам.

С другой стороны - городить отдельный вспомогательный джоб для генерации хранимок тоже не очень хочется.

Todo: уточнить хватит ли прав у
пользователей для выполнения динамического SQL.
---
env,
Нет, вряд-ли будут огромные расходы на "парс", все-же задача в моем случае просто проверить пару десятков уже готовых значений - на соответствие некоторым допустимым диапазонам.
Это не таблицы сканировать, а простое сравнение на больше/меньше/between/ и тому подобное.
Скорее, опасаюсь проблем с безопасностью при использовании генрации SQL.
Могут завернуть динамический код безопасники.
И это еще не самый худший вариант.
Хуже - если решение пройдет "в бой", а потом возникут проблемы.

О, идея!
Не надо мне генерить ни SQL, ни хранимки

Достаточно написать одну хранимку, которая работает с одним контролируемым параметром и умеет делать для него абсолютно все виды проверок - при этом - ветвлением через IF переходим на нужную в этот раз проверку, а
затем продолжаем в цикле вызов хранимки для другого
контролируемого параметра или выходим, если получили "стоп" - результат.
Создать только группы элементарных взаимосвязанных проверок с условиями переходов и остановок.