Alex SYo.!
с чего бы одинокой субд быть более перегруженой если ресурсов она будет тратить много меньше чем апп сервер+субд+гоняние трафика между апп-сервером и субд ?
от того что ты зарезервируешь апп-сервер субд под апп-сервером надежней одинокой субд не станет. да и резервировать одинокую субд (standby, репликация, лог шипинг) и гонять RO репорты на стендбай не так уж сложно.Ну, процедурные расширения тоже не святым духом работают, не знаю что займет больше ресурсов: передача результатов одиночного запроса (то что вы называете гонянием трафика) или хранение этого буфера в процессе процедурного расширения - дисковый кеш, блокировки и все такое. Если в первом случае субд отдала данные и свободна, то во втором ? И это на фоне большого количества конкурирующих сессий в субд. Разумеется, что во первом случае уже апп-сервер потребляет ресурсы при обработке данных, и, возможно даже бОльшие - это уж как система построена. Но в таком случае это могут быть ресурсы уже другой машины (машин).
Нередко приходится видеть вообще умопомрачительные вещи, реализованные в субд: типа разбора всяких файловых форматов, всякие парсеры, работа с pipe-ами, портами, отслеживание изменений в дисковых папках, работа с e-mail и т.п. Имхо это совсем не разумное использование ресурсов СУБД. Еще рано или поздно в таких системах появляется парсер формул, реализованный на субд, а то и несколько. А все из-за выбранной архитектуры.
Впрочем, все imho. Мой выбор (апп-сервер(свой) и субд) был сделан 10 лет назад и я не пожалел. Более того, сейчас я вижу много конкурирующих проектов в своей отрасли, переходящих к такой архитектуре. Средства при этом используются различные (покупные j2ee сервера, свои разработки) но движение в сторону n-звеньев есть. Кстати стало проще интегрироваться с такими системами, имеющимися у заказчика - многие стали поддерживать SOAP.По-моему, упускается из виду то, что бизнес-логика всё-таки часто должна работать с данными, а средства АПП-сервера работать с данными не умеют.

В них просто нету таких средств; любую работу с данными придётся реализовывать с нуля, всю-всю работу с множествами, с разпределением вычислений на процессоры и т.д., и т.п.

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

Если взять большие системы с серьёзными АПП-слоями типа SAP, то в них БЛ не перенесена на уровень АПП-сервера, у них некое промежуточное решение: на уровне АПП-сервера сделано фактически только хранилище бизнес-логики.

Т.е. это значит, что БЛ только хранится в АПП-сервере, но выполняется в СУБД.

Это требует очень больших затрат ресурсов на разработку, и компенсируется уменьшением зависимости от разработчика СУБД, что, конечно, важно для компании, затративший на создание системы труд сотен разработчиков (разработчиков в широком смысле) в течении десятков лет.
Бизнес, давая такое задание разработчикам, должен очень серьёзно подумать, за счёт чего и в какие сроки окупится это многократное увеличение затрат ресурсов на разработку.

А вот примеров реализации более-менее сложной (требующей какой-то работы с данными, а не только запросов Key-Value) логики именно в АПП-сервере (и исполняемой именно на АПП-сервере) я не знаю, и нынешние моления на ORM "применять всегда и везде" считаю абсурдными.

И ещё раз хочу заметить (на это уже обращали внимание), что в n-уровневой архитектуре бизнес-логика практически всегда распределяется между уровнями (т.е. нет уровня без бизнес-логики) - собственно, в этом и смысл такой архитектуры. Нужно уж очень сильно искуственно противиться такому разделению, чтоб его не было.

Т.е., ИМХО, правильнеый путь:
- БЛ распределяется по уровням
- на уровене клиента - логика с минимумом сложности и без обращения к данным
- на уровне АПП-сервера - логика с минимумом обращения к данным и с работой с внешними по отношению к СУБД объектами.
- на уровне СУБД-сервера - логика, связанная с работой с данными

Само собой, если логики, связанной с работой с данными нет (а таких приложений немало), то можно использовать и всякие ORM, и использовать СУБД толькло как хранилище.