vahСкажите пожалуйста,
корректно ли хранить текст sql запроса грида в таблице базы данных?
Заранее благодарен.
А почему бы и нет? Вполне корректно. Главный плюс (на мой взгляд) в том, что ты сможешь изменять логику запроса без перекомпиляции программы.

Petro123vah,
Тогда в клиенте ничего не останется))
Логично?
Ну почему же?! Останется код для работы с таблицей, содержащей запросы.
Вообще, полагаю, тут надо спрашивать не "корректно ли?", а "какую проблему будем решать такой архитектурой?" Если нужна возможность встроить в свою программу возможность настройки SELECT-запросов, то решение, на мой взгляд, годное. Если правка запросов в процессе эксплуатации программы не предполагается, то такое решение бессмысленно.

Сон Веры ПавловныЕсли поменяются метаданные результирующего набора (количество полей, имена полей, типы полей) , то клиентский код всё равно придется править и перекомпилировать.
Согласен. Но при некоторой ловкости рук можно и форму, на которой отображаются данные такой выборки сделать настраиваемой. Чтобы менялось количество, тип, формат отображения и пр. для столбцов грида.

Сон Веры ПавловныЕсли меняется только внутренняя логика запроса, то для этого специально придумали представления и табличные функции.
Согласен. Только представления и табличные функции - это объекта базы данных. Т.е. для их изменения пользователю надо будет выдать специфические права на уровне СУБД. Не факт, что админы БД воспримут эту необходимость с пониманием. А в случае с хранением запроса в таблице можно попробовать делать новую версию запроса доступной только после ее валидации админом БД и, например, админом безопасности. Ну это пир условии, что ТС версионность запросов реализовать захочет.

Да много чего при таком подходе можно намутить. Вопрос лишь в том: что надо ТС. Нужны ли ему те возможности, которые предоставит такая архитектура.