Составление выражений WHERE для SQL запросов

Необходимо разработать некоторый API, который был бы удобен и интуитивно понятен программистам для составления выражений WHERE в SQL запросах.
Например есть какой-то объект (таблица в БД), которая отображается в гриде, хотелось бы ее фильтровать по каким-то условиям. Предположим, что форма для фильтрации содержит нужные контролы, подставляя значения в которые, мы добавляем в выражение WHERE ограничения.
В принципе, это частный случай разбора математических выражений, но прежде чем разобрать это математическое выражение, необходимо ее еще записать на этом API.
Например каким-то образом надо отфильтровать объект по выражению:

(((expr1 and expr2) or expr3) and (expr4 or expr5 or expr6)).

где exprN - это что то типа:

field = value

Как записать выражения такого рода на API и сделать этот API интуитивно понятным.

Добрый день! В принципе, подобный API я писал, и еще писал GUI к нему. Если интересно, пишите сюда
-----------------------------------------------------------
Sorry for my terrible English, my native language is C++

А чем вам T-SQL то не нравится? Нормально там все выражается...

Варианта тут только два - либо хочется переписать SQL, либо хочется запретить программерам писать inline sql...


Cheers
Pete

T-SQL нравится всем и полностью. Но честно скажу, с таким API работать удобнее.
-----------------------------------------------------------
Sorry for my terrible English, my native language is C++

Да, согласен, с API работать удобнее...Особенно тем программерам которые плохо разбираются с SQL. Все что им нужно знать так это какие контролы на какие поля должны влиять (т.е фильтровать). Еще один важный момент так это если на форме которая предназначена для фильтра расположено куча контролов и каждый фильтрует какое-то поле, так вот если мы один контрол дизейблим, так надо же учитывать и оператор который перед ним стоял (OR, AND...) и что перед оператором...В общем лазить по бинарному дереву построенного выражения WHERE и убирать лишние скобки. А если разработать API то и задумываться над этим приходится меньше и ошибок в коде меньше тем более что если фильтры строятся динамически...

Архитектурой попахивает...

Все попытки переложить формирование сиквела в API на функциональных языках программирования заканчивались плохо... Из тех, что я видел и сам когда-то писал, конечно :)

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


Cheers
Pete

IMO такой API оправдан в случае необходимости портирования или обеспечения работы системы с разными СУБД.
В иных случаях затраты на проектирование и написание не оправдывают результат.
Что же касается "универсального динамического фильтра", то тут ситуация такая же. Зачастую (я не хочу обобщать) гораздо проще узнать у пользователей что и по каким критериям они хотят фильтровать именно в этом режиме.

Посмотри тут - может, то что надо?

Писал я как-то CRM систему. И вот когда дошло дело до системы поиска, я загорелся желанием сделать универсальный построитель запросов. Промучился 2 месяца и сделал.
Вот в таком виде:

- Фирма - И - Наименование = 'А%' - Менеджер - ИЛИ - Наименование = 'Б%' - Наименование = 'Рога и копыта' - Папка - И - Наименование = 'личная'

Для визуального построения использовался контрол - дерево. На основании метаданных каждый класс предоставлял список своих атрибутов. Все замечательно и красиво, можно построить какой угодно запрос. Но пользователям это не понравилось. Слишком сложно. Гораздо проще построить 2 десятка запросов с определенными параметрами. После чего я так и сделал. Все довольны. Когда пользователи хотят получить еще один отчет, я пишу хранимую процедуру и все. Во-первых на T-SQL я могу построить запрос намного изощреннее, а во-вторых такой изощренный запрос пользователи не смогут построить даже с помощью такого универсального построителя запросов.

Мне не для пользователей необходим постороитель запросов а для программистов и вопрос о том сложно или легко ложится на класс - построитель, а освоение предоставленного API - дело техники.