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

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

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

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

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

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

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

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

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

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

Kachalovalexeyvg
Дополнительно: превозносимая многими возможность разделения системы на сотни дешёвых АПП-серверов объсняется тем-же - приложения не работают с общими данными. Если можно данные в БД разделить на независимые кусочки, тогда и такие БД можно разнести на сотни и тысячи независимых дешёвых СУБД-серверов...
- где-то видели работающий пример реализации Вашей идеи распределения логики по многим дешевым СУБД? (интересно почему Вы не использовали модный термин "шардинг"?). Если говорить о кластеризации на уровне Application-сервера, то это реально работает ;)Да, видел.

В MySpace использовалось 500 серверов MS SQL Server 2005 (сейчас уже больше)

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

Что дешёвый апп-сервер будет эту тыщу запросов в секунду обрабатывать, что дешёвый субд-сервер - без разницы.

Kachalovalexeyvg
Само собой, если логики, связанной с работой с данными нет (а таких приложений немало), то можно использовать и всякие ORM, и использовать СУБД толькло как хранилище.
- улыбнуло. Если я правильно понял последний тезис, то ORM можно использовать там где нет данных? Или я не понимаю что такое "логика, связанная с работой с данными"?Совершенно верно поняли.

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

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

Kachalov- все это есть в современных ORM (распределенные объектные транзакции - это важный элемент спецификации EJB)Это конечно, так, но вот в чём вопрос - не эффективнее ли транзакции и вообще сложные манипуляции с данными делать на том сервере и на том языке программирования, который для этого и предназначен?