Если нужен статический SQL для Java-кода, то нужно смотреть в сторону SQLJ, или новомодного pureQuery.

Semen PopovЕвгений ХабаровЕсли нужен статический SQL для Java-кода, то нужно смотреть в сторону SQLJ, или новомодного pureQuery.Спасибо. То есть вообще можно отказаться от ХП? Даже в реализации отчётов, где обычно использовались ХП? Преимущества? Я думал, что реализация на уровне СУБД является самой оптимальной (конечно, зависит от самой реализации, кода). Но вот для того примера - отчёта, который формируется в ХП. Будем считать, что код идеальный. Если отказаться от ХП и вынести код в SQLJ, то этот вариант будет оптимальнее?
Отказаться от использования ХП можно, вопрос нужно ли.
Оптимальнее нужно по какому критерию или критериям?
Точек зрения на оптимальность всегда больше одной.
Если в процедуре кроме самих запросов "зашить" вычисления (бизнес-логику), то эта логика эта будет выполняться на стороне сервера и использовать его вычислительные ресурсы. Это может быть как плюсом, так и минусом.
Если необходимо "закрыть" исходные таблицы БД от прямого доступа, то для этого понадобятся хранимые процедуры и/или VIEW.
Еще один параметр, сколько изменений понадобится при изменении алгоритма расчета?
В случае хранимой - это изменение самой хранимой внутри БД. В случае клиентского ПО, которое напрямую работает с БД - изменение каждой копии этого ПО. В случае когда клиентом БД является сервер приложений - изменение одного приложения внутри сервера. И т.д.
Что является критериями оптимальности в Вашем случае?

Semen PopovЕвгений Хабаров
Отказаться от использования ХП можно, вопрос нужно ли.
Оптимальнее нужно по какому критерию или критериям?
Точек зрения на оптимальность всегда больше одной.
Если в процедуре кроме самих запросов "зашить" вычисления (бизнес-логику), то эта логика эта будет выполняться на стороне сервера и использовать его вычислительные ресурсы. Это может быть как плюсом, так и минусом.
Если необходимо "закрыть" исходные таблицы БД от прямого доступа, то для этого понадобятся хранимые процедуры и/или VIEW.
Еще один параметр, сколько изменений понадобится при изменении алгоритма расчета?
В случае хранимой - это изменение самой хранимой внутри БД. В случае клиентского ПО, которое напрямую работает с БД - изменение каждой копии этого ПО. В случае когда клиентом БД является сервер приложений - изменение одного приложения внутри сервера. И т.д.
Что является критериями оптимальности в Вашем случае?То, что Вы описали имеет место быть и для моих критериев. В моём случае приложение крутится под WAS 6, который является клиентом базы. Но я бы хотел подойти к вопросу с общей точки разработки ПО под DB2. Наверняка существуют основные моменты, которые являются законами в разработке приложений под СУБД DB2. Например, в производительности, скорости выполнения операций. Что лучше - SQL-скрипт вставки записи или вызов созданной на уровне бд ХП или тот же ORM или SQLJ? Или, например, критерий уменьшения сетевого трафика. Что создаст меньший трафик - выполнение приложением SQL-скрипта по вставке записи или выполнение ХП вставки записи? И т.д. У меня есть знакомые разработчики, которые придерживаются мнения, чтобы всю касаемую данных логику хранить в DB2. Она сама всё оптимизирует.
It depends .....
Пример 1:
1. Вызов хранимой это скорее всего динамический SQL-запрос. Считаем затраты на его Prepare, bind-параметров, плюс возможно преобразование типов параметров.
2. Внутри хранимой программный код должен эти параметры получить, выполнить программную логику и заложенные в эту хранимую SQL-операторы.
Если внутри хранимой простой INSERT, то в таком случае использование хранимой будет оправдано в случае, если хранимая выполняет логику по проверке входных параметров на допустимость и/или скрывает от потребителя внутренние таблицы БД.
Иначе использование промежуточной хранимой даст только доп.задержку в обработке. Т.е. INSERT из прикладной программы (а если еще и пакетный, то тем более) скорее всего сработает быстрее.
Пример 2:
Требуется обработать миллион записей исходной таблицы (или таблиц) для формирования итоговой выборки на сотню записей. Причем одним SQL-оператором желаемую выборку получить невозможно, т.е. требуется чтение каждой записи. В таком случае хранимая процедура даст выигрыш по сравнению с сетевым приложением, т.к. не нужно будет гонять большой объем трафика по сети.
Однако, если приложение исполняется там же где и БД, то выигрыш хранимой будет не столь очевиден.
Пример 3.
Динамический и статический SQL.
Если правильно пользоваться динамическим SQL, то он будет почти не медленнее чем статический SQL и будет использовать имеющуюся на момент Prepare статистику.
Однако в динамическом SQL выше шанс нарваться на ошибку во время исполнения SQL, если допустить ошибку в синтаксисе запроса или в типе переменных. С другой стороны большая гибкость.
Статический SQL должен давать прирост производительности за счет пропуска фаз Prepare, проверки прав, построения плана доступа и привязки переменных. Однако "свежая" статистика будет использоваться только после операции REBIND пакета. Т.е. затрат на администрирование кода чуть больше.
Разнесение бизнес-логики между СУБД и сервером приложений может иметь смысл хотя бы по соображениям балансировки нагрузки. Если вся логика будет выполняться в СУБД, то сервер приложений (вернее сервер на котором он выполняется) будет "простаивать". Может быть и наоборот.
Еще раз, It depends......... ;-)