Ну вот, старые песни... Масштабируемость, упрощение... Баян...

Странные мысли о 3-звенном приложении

ХерресЯ бы ещё добавил так: главное в том, что трёхзвенка - это способ разменять скорость и простоту разработки (и в итоге - более мощный функционал) на скорость.

Можно по-подробней... Про скорость и простоту... Вместо обработки данных на сервере СУБД (предназначенными специально для этого средствами) - обработка на среднем уровне? Где здесь скорость? Вместо сосредотачивания на разработке только серверного кода - размазывание его между сервером СУБД и апп. сервером. Где здесь простота?

авторИ размен этот очень достойный, ибо железо дёшево, только функционал имеет значение.

Дешево что по сравнению с чем?! Вместо того, чтобы умощнить (сделать кластер) сервер СУБД, мы будем приобретать отдельное железо под апп. сервер?

авторРазмышления технических спецов о кем-то принятых бизнес-решениях - это что-то :-) (без обид, сам грешен)

Как мне казалось, в топике идет обсуждение именно технических вопросов, а не стоимости проектов и % откатов. ;)

2 Сисой

авторРаспараллелить СУБД на нескольких машинах хотя и возможно архитектурно, но гораздо гиморнеее, чем вычисления на нескольких app-серверах. Не надо думать, что в учетных системах не хватает расчетов - простой посменный расчет загрузки в MES-системе обрушит производительность SQL-сервера довольно прилично. СУБД должна заниматься своим делом - транзакциями и выборками, а не ветвлениями и циклами.

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

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

Ага. Т.е. в СУБД (которая как раз и расчитана на "сложную логику взаимодействия параллельных конкурентных процессов") это не реализовать - лучше будем свой велосипед изобретать?! А что, апп. сервера потребуют МЕНЬШЕ ресурсов?!

автор3. Тонкие клиенты. Используя только 2х-звенку, проблематично построить приятный взору и эффективный интерфейс взаимодействия пользователя с клиентом. Терминал - не всегда панацея.

Давайте так. "Приятность взору" интерфейса никак не коррелируется с числом звеньев в архитектуре системы! Если Вы про WEB интерфейс, то, IMHO, его с большой натяжкой можно назвать "приятным взору".

2 iscrafm

В Ваше фразе заменяем "сервер приложений ISCRA" на "сервер СУБД" и получаем:

1. Управляет контентом.
2. Взаимодействует с БД (одной или несколькими) по запросам пользователей
3. Исполняет логику, которая реализована не средствами БД (срипты Object Pascal,JAVA или просто dll которые решают определенные задачи. Например, массовая рассылка корреспонденции)

5. Обрабатывает пакеты данных получаемые от клиента и передаваемые ему (шифрование, сжатие и т.п.)

Если Вы считаете, что современные сервера не умеют этого делать, то Вы не правы.

автор
4. Управляет лицензиями, в том числе и на СУБД

Вот это "управление" мне не совсем понятно - растолкуйте, плиз.

авторНе конектить же клиента к одновременно к нескольким БД. Особенно через интернет. Типичный пример сервера приложений - web сервер. Думаю понятно, что он делает такого, чего нельзя сделать при помощи СУБД.

Я не отношу себя к противникам N-звенок. Я противник использования их там, где достаточно функционала СУБД.