Поковыряйте поиск. Обсуждалось немыслимое количество раз в самых разных форумах.

rodbЕсть одна причина на которой будет полный тупик.
Работа через интернет.
Простой клиент-сервер будет всегда работать через медленно.
:)

rodbВремя прохождения запроса в интернет увеличивается квадратично, если запрос должен вернуть клиенту какие-то данные и клиент на основе их должен опять сделать запрос, то программа начинает тормозить до безобразия.
Поэтому идеальным для работы в интернет будет когда, все вычисления
делает сервер приложений и возвращает клиенту одним пакетом.
То, что Вы описали, называется вовсе не клиент-сервер. Это называется "вся логика на клиенте". И это расхождение ставит под сомнение истинность Ваших утверждений.

BRitaа вот если так, скажем: сервер Oracle, много удаленных клиентов и нужен доступ по интернет, тогда добавляем скажем Apache+ Php это как уже можно назвать трехзвенкой или нет?
Фанаты - считают. Лично я полагаю, что это скорее нечто типа удаленной клавиатуры; такая же "трехзвенка", как если я зайду RAdmin-ом или другим удаленным десктопом на чужой компьютер (или например терминальный сервер) и запущу оттуда клиент-серверное приложение.

Если серьезно - зависит от того, что за Php. Ключевой признак трехзвенной архитектуры - наличие именно Сервера Приложений, то есть некоторой программы, которая обеспечивает нетривиальное совместное обслуживание многих пользователей. В той архитектуре, которая обычно имеется в виду под Apache+Php - apache работает брокером клиентских запросов, БД собственно обслуживает, а Php форматирует результаты селектов - трехзвенной систему можно назвать только сугубо формально.

BRita
Написано же. Хотя читать, конечно, тяжело.

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

1024ну, мне кажется причина всё таки есть - это масштабируемость, т.е. когда решить проблемы производительности нельзя другим способом.
А когда их нельзя решить другим способом? Имхо - только если изначально выбрали плохо масштабируемый сервер БД. То есть, на пальцах, если БД ограничена 2Gb, а данных становится больше - сервер приложений может скрыть это, начиная размазывать данные между несколькими экземплярами БД. Но мораль этого - не нужно изначально делать глупостей, и потом не придется вешать неуклюжие заплаты.

Общие положения:
трехзвенка не решает ни проблем быстродействия (наоборот тормозит), ни вообще никаких проблем, усложняет разработку системы, усложняет отладку и тестирование.
Вобщем сделать это можно, но зачем?
Определенные проблемы трехзвенка таки решает. Например, представьте себе систему, которая в реальном времени предоставляет доступ к данным из кучи исхочников - just for example, какие-нибудь биржевые котировки со всего мира. В клиент-серверной архитектуре пришлось бы вязать клиентов с серверами схемой "все со всеми", имея все минусы такого подхода. В трехзвенке AS развязывает этот узел, позволяя прозрачно подключать новые источники данных, реагировать на смену форматов; может быть организовано более эффективное, предсказывающее кэширование, могут быть реализованы механизмы, отсутствующие во всех или некоторых источниках (например, оповещение о критическом изменении котировок) итп.