Конструктор запросов mysql. Прошу помощи.

Дамы и господа, прошу помощи.. Второй день сижу с карандашом, никак не могу придумать.

Есть задачка, ускорить создание форм поиска для корпоративной интранет-системы и дать возможность руководителям самим создавать предустановленные фильтры для списков и сохранять их. Далее, чтобы сохранённые фильтры выводились ссылками вверху списка и по нажатию фильтровались.

Для разработчиков хотелось бы, чтоб они простым описанием в коде одного поля из базы сразу получали на выходе html-форму и автоконструирование запросов.
То есть чтоб писали в коде что-то типа

$ar=array(

"table" =>"person",

"filter" => array(

       "category"=>$category,

  ),

 "formelement" => "dropdown",

 "formsource" => "select category from person group by category"

);

$oForm = new FilterForm($ar);

$oForm->generateHTML();

тут я грубо накидал, примерная структура хранения секции WHERE понятна, а если запрос с JOIN-ами, вложенными подзапросами и прочим - хз. И как-то это всё по полочкам надо хранить в базе, чтобы представлять удобный конструктор для создания таких фильтров в HTML.
То ли задача невыполнимая, то ли опыту мало... Не получается придумать как SELECT разложить в массив, хранить по секциям FROM WHERE ORDER GROUP в базе и как универсализировать вывод этого всего в форму %)

Никто не сталкивался с такой задачей?

Капай битрикс. там такое было

В битриксе не так, они на каждую таблицу-модуль пишут свой класс в котором уже описывают фильтр. Массив $arFilter, который передаётся метод getList решает проблему с WHERE, но не решает задачу со всем остальным.
А хотелось бы один класс-конструктор, который будет использоваться для большинства таблиц

Может посмотреть в сторону ORM?

Ну посмотреть то можно, вот только переехать на неё с уже полтора года работающим продуктом вряд ли получится

Цитата ("alexander_vip"):

тут я грубо накидал, примерная структура хранения секции WHERE понятна, а если запрос с JOIN-ами, вложенными подзапросами и прочим

Ваша задача — типична, существуют тысячи реализаций. Можете глянуть, как это описывается в Hibernate, статья на Хабре: ссылка (там Java код можете пропустить, но присмотретесь внимательно к XML конфигам, описывающим таблицы и взаимосвязи).

Если показать на пальцах, в PHP такой вариант может быть таким (сходу придумал):

$datasources = array(

    'person' => array(

        'type' => 'table',

        'tablename' => 'person',

        'fields' => array('personid', 'name', 'age')

    ),

    'person.adult' => array(

        'type' => 'subquery',

        'source' => 'person',

        'fields' => array('personid','name')

        'filters' => array('age>=21'),

        'orders' => array('personid')

    ),

    'driver' => array(

        'type' => 'table',

        'tablename' => 'driver',

        'fields' => array('personid', 'licensenumber', 'description', 'validationcode'),

        'filters' => array('licensenumber is not null', 'validationcode=?'),

        'relations' => array(

            'personid' => array(

                'type' => 'exists'

                'source' => 'person.adult'

                'field' => 'personid'

            )

        )

    )

);

На самом деле тут возможен миллион вариантов реализаций... смотрите как Вашей команде удобно работать.
Хотя хорошо бы, чтобы ключевые слова с каким-либо распространенным ORM совпадали.
А вообще лучше действительно не городить велосипед, а, если уж не заботитесь о производительности (это видно по данной задаче, так как те, кого заботит производительность, такие конструкторы в PHP не используют вообще), то действительно смотрите в сторону какой-либо известной ORM.
В любом случае, так можно создавать SQL запросы любой сложности. Но нужно ли?

P.S. Как по мне, на два порядка проще, и намного красивее было бы такое тривиальное решение:

$oForm = new FilterForm($querycode, $parameters);

$oForm->generateHTML();

Где $querycode — это код SQL запроса из репозитория всех запросов (или, опционально, даже сам SQL запрос), а $parameters — опциональный массив параметров запроса.

tvv, спасибо за обстоятельный ответ! Есть пища для размышлений

Для таких целей, ИМХО, идеально подходят хранимки

+1000
хранимки - это сила.