2 Павел-П
А вы проведите тест. Сгенерируйте огромное количество данных. И выполняйте свой запрос под большой нагрузкой. Вот и получите ответ.
Да мне то нахрена это надо? Я и так знаю, что получится в итоге.
Вот Вы можете попробовать сотворить в нулевом приближении ебайную эмуляцию.
Сервер БД, веб-сервер, страничка.
В первом варианте со страницы уходит простой селект.
Во втором варианте со страницы уходит обращение к хранимке, содержащей тот же самый простой селект.
Попробуйте заметить разницу во времени. Может хоть после этого эксперимента перестанете по форумам мудачества писать на тему "затрат ресурсов на компиляцию хп".

Исходя из ваших аргументов - хранимые процедуры это зло.
Нет.
Я далёк от мысли демонизировать хранимки. Но я их и не идеализирую. В отличие от многих здешних участников, которым даже лежащее на поверхности утверждение о том, что ХП могут быть медленнее, требуется в рот положить да расжевывать. Настолько они готовы на хранимки молиться, что им даже в голову не приходит, что там может быть что-то медленно и/или что-то плохо.

Ими вообще пользоваться не стоит. А вдруг они вообще работать откажутся в движке СУБД.
Вам - возможно и не стоит пользоваться. Тем более если они у Вас "вдруг" перестают работать.

Поэтому будем пользоваться обычными запросами.
Дык и до написания запросов не факт что Вас стоит допускать.
Use ORM.

А то что запрос на сервере надо скомплировать - это никаких ресурсов не требует (об этом мы умалчиваем).
Да нет, не умалчиваем. Вон, условия для эксперимента я чуть выше нарисовал. Дерзайте.
BTW, сервер БД предназначен для того, чтобы запросы исполнять. И если для простых запросов (а сложным запросам в ебайно-подобных приложениях взяться просто неоткуда) составление плана их исполнения вызывает какие-то существенные затруднения - то это есть веский повод задуматься.

А вы знаете иногда оптимизатор неверно строит план запроса и для обычных запросов.
В этом случае, как я думаю, хранимые процедуры опять таки не будут иметь преимущества. У них будет точно такой же неверный план запроса. Так что Ваше "хранимые процедуры никогда не уступят в производительности" не становится менее ложным только от того, что оптимизатор может ошибиться.

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

2 Yo.!
допустим были table1.a и table2.a интами, поглотили конкурента пришлось table1.a на варчар поменять. в хп субд проблему обнаружит, а как тесты DL узнают о связи table1.a с table2.a и отловят проблему ?
Если кто-то, выражаясь соседским языком, ёбнут на своей гордости от умения выписывать data access layer, то ему не составит труда написать валидацию схемы. Если же нет желания велосипеды изобретать, то существуют нормальные ОРМ.
Есть маппер, у него внутре думатель и неонка. Если думатель не смог корректно отмапить, то загорается неонка.
Билд проекта не пройдет. Какие ты тут мировые проблемы увидел - загадка.

---------------------------------

2 DPH3
В голову закрадывается страшная мысль - может, ты изменения в хранимых процедурах вообще не тестируешь, рассчитываешь только на контроль со стороны Oracle?
И, кстати, есть какой-нибудь аналог junit для хранимых процедур?
О чём ты, товарисч?
Истину говорю, они застряли на этапе квик-бейсика для мс-дос.
То, что в самых продвинутых СУБД иногда не компилируется некомпилируемое - уже воспринимается как божье откровение.