.NETВопрос по проектированию.
Имеется набор параметров p1, p2, p3, ... pn разных типов.
Необходимо организовать хранение логических выражений составленных
из этих параметров, знаков сравнения (>, <, =) и логических связок (И, ИЛИ)
Например: p1 > 100 И (p2 < 'ertey' ИЛИ p2 = p3)

При этом желательно предусмотреть возможность измененения набора параметров в будущем.
А так же возможность эффективной фильтрации по входным параметрам.
Например известно, что p1 = 35 и надо быстро отобрать все выражения, которые могут
быть истинными для такого значения p1.

Вот такая приблизительно задача.

У меня есть некая идея: хранить параметры в строках отдельной таблицы, чтобы их можно было
легко добавлять. Выражения хранить в другой таблице в виде дерева, где узлам соответствуют
логические связки, а листьям элементарные выражения сравнения, которые будут храниться в
третей таблице. Вот как-то так. Но по такой схеме очень сложно организовать фильтрацию.В общем, для хранения описания логики терпимо, но только вы, скорее всего, просто "утонете" в множестве вариантов при обработке. Особенно, если учесть существование NULL и UNKNOWN, да и LEFT/RIGHT/FULL слияния оптимизма не добавляют. В результате почти наверняка начнёте организовывать некий конвейер для последовательной обработки и, как пить дать, придете к процедурному подходу, который при работе с РСУБД является не самым удачным решением. Да и далеко не самым быстрым. Написать даже самый простой оптимизатор выражений уже само по себе трудоёмкое занятие. Да, в общем-то, и не нужное, так как в РСУБД он и так уже в наличии, причём нет никакой уверенности, что вы сможете сделать лучше.
Таким образом вполне вменяемым вариантом можно считать формирование самого запроса с подстановкой параметров на клиенте и отсылка его на выполнение РСУБД. Она сама разберётся каким наилучшим образом выполнить запрос. При острой необходимости, можно также формировать запрос и на сервере, так как практически все позволяют запускать динамические запросы, т.е., сформированные в виде строки.

.NETChA
Таким образом вполне вменяемым вариантом можно считать формирование самого запроса с подстановкой параметров на клиенте и отсылка его на выполнение РСУБД. Она сама разберётся каким наилучшим образом выполнить запрос.
Я, вообще-то, не хочу оптимизировать SQL Server с помощью какой-то своей логики обработки запросов. Просто пользователь вводит на клиенте набор параметров p1, p2, p3,..., pn и программа должна проверить удовлетворяют ли эти параметры некоторым логическим выражениям. При этом я не могу хардкодить эти выражения на клиенте, потому что предполагаеться, что пользователь может сам добавлять и модифицировать эти правила. Т. е. мне надо их хранить на сервере в каком-то виде. Или Вы предлагаете такой вариант:
создать на сервере служебную таблицу с колонками соответствующими параметрам, перед проверкой инсертить набор параметров в эту таблицу, а выражение которое надо проверить хранить просто ввиде SQL-фильтра.
При этом процедура проверки будет заключаться в выполнении выборки из служебной таблицы по этим фильтрам. Но это опять таки будет медленно работать, если выражений будет очень много.Или Вы неправильно поняли, или я слишком далеко зашёл.
Вы можете хранить все параметры любым, приемлимым для Вас способом, хотя бы описанным в первом же топике. Главная мысль заключалась в том, чтобы потом, когда возникнет потребность выполнить всю комбинацию предикатов, то не просчитывать её последовательно, один за другим, с хранением промежуточных результатов, а формировать весь запрос сразу, целиком. А затем отправлять его на выполнение. Пусть сервер сам разбирается, что и в какой последовательности вычислять, наверняка он выберет наиболее оптимальную стратегию, чем если "вручную" выберете её Вы.