Здравствуйте, mr_dino, Вы писали:

_>встретил мысль на форуме, что динамическое формирование SELECT часто представляет неудачное решение.
_>В моем проекте такое встречается.

Добавлю свои пять копеек.
Я вижу динамическое формирование SQL как вариант увеличения производительности приложения. Понятно, что если запрос формируется динамически, то код, который это делает, является разбросанным. Часто даже куски такого кода находятся в разных функциональных модулях приложения. Но подобная децентрализация формирования запросов позволяет достичь существенных результатов. Пример — табличное представление списка документов (ессно с возможностью постраничной навигации, сортировкой, опцией jumpto и т.д.). В зависимости от того, что юзер щелкает на гуях, запрос получает то или иное navigation clause. Хибернейт врядли умеет правильно и оптимально сам построить подобные запросы. У него другая роль.

Теперь насчет хранимых процедур. В идеале — весь код по работе с хранилищем данных лучше бы запихнуть в саму базу, то есть в процедуры. Они и прекомпилированы (то есть не разбираются заново при каждом обращении), и просто количество трафа ниже — нужно передать только параметры, ибо сам код уже в базе. Но это в идеале. Если система состоит из модулей, то часто нужно, например, к основной процедуре вставки бизнес-объекта в базу (разложить по нескольким табличкам), выполнить еще и сохранение какого-нить функционального "расширения" этого объекта, принесенного дополнительным модулем. Если без процедур — все просто: выполняешь по очереди запросы на сохранение из каждого модуля и все. Хранимая же процедура должна бы в таком случае владеть конфигурацией приложения. То есть, по сути, кроме своей основной задачи, выполнять еще и роль контроллера какого-то. Впрочем, если напрячься, то это наверное не является препятствием. Просто каждый модуль вместо выполнения своих запросов просто вызывает "свои" процедуры с передачей им module-specific параметров. Подход кажется вполне рабочим, только я пока не пробовал так делать.