Тут примерно так получается: вынужден полностью поддержать ЛП, хотя я с ним "категорически не согласен".
Начну с моих акцессных ответов на первоначально поставленные вопросы.

st_stСильно ли тормозят хранимые процедуры, по сравнению с обычными запросами из web-приложения?

Хранимые процедуры не "тормозят по сравнению с обычными запросами" ни из web-приложения, ни из какого другого.

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

Самая главная военная тайна в приложениях а-ля магазин-ебай заключается в том, что там нет данных, которые надо "обрабатывать".
Зато там есть масса данных, в которые надо глядеть глазками и жмакать по ним ручками с толстыми или тонкими пальцами. "Обрабатывать" на стороне web-сервера в таких задачах физически нечего. Нет там никакой (сложной) "бизнес-логики", требующей применения слова "обрабатывать", что подразумевает выполнение пакетных заданий над большими массивами однородных данных. По крайней мере - на стороне web-сервера, обращенного лицом к конечному покупателю.

Для такой задачи - двухзвенное решение предлагается или n-звенное - хранимые процедуры - козе баян, усложняющий хождение по кочкам и буеракам развития системы.

Пусть мне сказали - пиши такое на акцессе. Нужно быть ъбнутым на своей гордости от умения писать хранимые процедуры, чтобы подвязать пользовательский интерфейс на хранимки против ad-hoc запросов. Образовать грид на View - значит отдать полностью на откуп встроенным средствам
( в моем случае - акцесса) вопросы, связанные на фильтрацией, синхронизацией/рефрешем данных, записью в базу и обновлением. Образовать грид на хранимой процедуре - значит предоставить разработчику возможность гордиться своими умениями выписывать запросы/хранимки на синхронизацию данных и обеспечивать хитроумные возможности (опять через хранимки) по вставке/модификации данных. (Это не упоминая о необходимости обеспечить опысываемость возвращяемых наборов)
Даже если вы ярый сторонник реализации "бизнес-логики" прямо в СУБД, это не обязательно должно означать, что весь код, поддерживающий визуализацию данных, обязательно должен находиться там же - в СУБД?

pkarklin Дело в том, что эти самые разработчики "морды" и понятия не имеют, как и что хранится и обрабатывается на стороне "бэкофиса" (СУБД). И "пускать" их в хранилище с "прямыми" запросами - это прямой путь к краху всей системы в целом. Уж поверьте...

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

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

В условиях, когда архитекторы хотят независимо горизонтально масштабировать приложение и систему хранения данных - отсутствие хранимого в СУБД кода, единственная цель которого - поддержать отображение приложением пользовательских списков выбора, выглядит как понятное решение.
Ни к "тормозят процедуры", ни "к перекинуть и обработать" это отношения не имеет.

Вот в чем я с ЛП категорически не могу согласиться. Никак.
Так это с тем, что хранилище - тупое. Негоже наделять хранилища человеческими качествами.

Yo.!...
угу, последний проект пришлось делать на жава+хибер просто по тому что pl/sql девелоперов на пару порядков меньше и стоят на порядок дороже и пока соберешь нормальную команду ...

не мне, акцесснику судить, но со стороны кажется прмерно так:

цена ява-програмистов падает по мере увеличения их количества. Но цены pl/sql - программистам уже почти нет. Уже ничего они не стоят. Почти.
Сейчас, мое впечатление, средний "vba-программист", имеющий весьма приблизительное представление о предмете, но способный произнести слов "Excel" и опознать его ярлык на десктопе, стоит дороже pl/sql девелопера
Деньги, которые получает ява-программист еще менее vba-шника зависят от того, насколько он в теме, ввиду жаренности самой явы и обширности ассоциированных аббревиатур.

Типа - pl/sql - пердуны - это чтобы поддерживать унаследованные системы.
Vba - ну, VBA никто не знает и знать не желает, чтобы соседи-профессионалы не смеялись.
Да и умер он уже почти достоверно. За это можно и приплатить временно.
А ява-пионэры - это наше все. Соременные технологии и куча терминологии.
Без них и базу данных в осколки не разобъешь по современному и будущему.
Это неважно, пишут ли они что практическое, или "технологии изучают" - священные коровы и временно стоят дороже ввиду того, что нужны абсолютно всем в строго обязательном порядке. Даже если неизвестно - что с ними в точности делать. Без них ярлыки современных технологий со лба спадают. Как-то так.

DPH3 Ну наконец-то появился кто-то с опытом разработки нагруженных систем :)
Был это юмор, ирония или сарказм - значения не имеет.
У меня нет опыта разработки не только нагруженных, но и вообще - чего-то такого, что можно было бы назвать словом "систем".

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

Временные задержи не от отсутствия потребности в целостности данных, а от неудавшихся попыток замести под ковер объективную нехватку производительности подсистем ввода-вывода, или есть следствие субъективного отказа от признания неудачи в выборе поставщика СУБД.

ЛПЭээ... позвольте заявить в своё оправдание, что очеловечивание хранилища с моей стороны можно рассматривать как акт социального протеста против (интересно, бывает ли протест за?) наблюдающейся тенденции обожествления этого самого хранилища. Тут же ж эттаа... хранилищу молиться готовы... особенно если оракл написано

:))
Ну, тогда уж несчастным его назови, что-ли.
Раскалывали хранилище на кусочки не предупредив, что с самого начала для того и выбирали, чтобы потом расколоть.

Чуется мне, что через какое-то время, совершив соотвествующую петлю, завершится это тем, что в современных терминах могло бы быть названо монолитным решением.
Будет эта какая-нибудь экзадата шрих энного поколения или диби-два-в-ионосфере - поживем увидим.