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

И нафига все это нужно?
В реальном бизнес приложении?

самопальные кэши - что бы потом делать самопальные блокировки? и самопальную транзакционность? а что, у СУБД кэши не предусмотрены? Интересна, какая нагрузка на приложение, что такая порнография понадобилась? Может просто научится индексами в БД пользоваться?

минимизировать количество сессий на СУБД (важно, если лицензирование ведется по количеству сессий) - сначала купить дорогую СУБД, а потом ее НЕ использовать? Если она не нужна, зачем тогда ее покупать?

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

ну и возможности языков типа JAVA и т.п., которые используются на серверах приложений, гораздо шире, чем языки СУБД - ряд СУБД позволяют внутри себя использовать Java. Ну и СУБД надо использовать для обработки ДАННЫХ. А тут, может язык СУБД и не настолько "широк", но значительно УДОБНЕЕ (сужу по PL/SQL). А на Java, ряд дятлов вполне могут полную hibrnate'изацию и приложения, и БД устроить. После чего, hibernate и наступит. И приложению и серверу СУБД. Вот тут как раз и потребуются и кэши и горизонтальная масштабируемость. Сами себе создаем проблемы, потом сами и решаем.

Готов для бизнес приложения признать единственную реальную необходимость еще одного звена, недо-сервера приложений: сервер отчетов или сервер job'ов . Который будет заниматься исключительно отчетами и/или долго рассчитываемыми job'ами (например массовыми операциями)

IMHO & AFAIK

Дядька с усами и часамиLeonid Kudryavtsevможно больше написать кода ==> выше заработокможет быть ещё какие-то аргументы?
Ну если Вы, знающий свою задачу, никаких достоинств не видите... то наверное главный плюс от переусложнения системы - потребовать за нее больше бабла. И за разработку и за саппорт.

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

Во всех других случаях, наверное, более простое решение и более выгодное.

IMHO & AFAIK

Dimitry SibiryakovLeonid KudryavtsevИ нафига все это нужно?
....
- workaround неспособности программиста написать нужную логику на языке СУБД и/или приложения.
мне кажется, можно оставить только одно
все предыдущие - просто следствие данного пункта

alexk123...Но если завяжитесь на бизнес логику внутри СУБД, то навечно и клиента "прикуете к ней", то сами уже не спрыгните....

А так - можно скоплектовать систему из одного или нескольких бесплатного сервера приложений и одной или нескольких бесплатных СУБД. И все это будет работать на технике не самого высокого класса. Вы цену владения такой системы для клиента рассматривайте, а не то что вам лично внутри СУБД удобно бизнес-логику писать.[/quot]

Сорри (((
alexk123...Но если завяжитесь на бизнес логику внутри СУБД, то навечно и клиента "прикуете к ней", то сами уже не спрыгните....

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

Просто, если по каким-то причинам решили купить "серьезную" СУБД, IMHO очень глупо не пользоваться теме возможностями, которые она предоставляет и за которые заплачены деньги. Покупать и платить за лицензии и техподдержку Oracle и при этом использовать его на уровне только стандартного SQL... можно конечно, но, подозреваю, в этом случае, что Oracle, что MySQL, что Postgre SQL будуд совершенно одинаково. Тогда нафига его вообще покупать? (вопрос функционирование экономики по методу распилинга и откатинга не обсуждаем)

С таким же успехом, ради переносимости, можно вообще СУБД не использовать... текстовые файлы - наше все.

Кроме того, не очень понятно, как кэши, переноимости, СУБД независимость и прочее, связаны с сервером приложений.

Нужны Вам дополнительные кэши, при чем тут сервер приложений? С таким же успехом (и даже эффективнее) можно и на клиенте данные кэшировать.

Нужна Вам кросс-платформенность от СУБД, ну так кто мешает, написать клиент-сервер не используя специфических фичь базы данных. С таким же успехом и клиент-сервер можно сделать независимым от вендора СУБД. Исключительно вопрос начального требований ТЗ и денег на тестирование. Что клиент-сервер нужно будет тестировать на разных СУБД, что трехзвенку, так же на разных СУБД нужно независимо тестировать. И так далее.

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

На старом, добром FoxPro - нужен один человек. Знающий FoxPro

Двух звенка, нужны C# и SQL'шник. Два человека.

Трех звенка: JavaScript, Java, SQL. Три человека

Ну или ищем full stack. Который об индексах знает, что "есть такая вещь и вроде позволяет скорость выполнения запроса увеличить". Или возьмем ORM, насоздаем объекты, а дальше оно все за нас само сделать должно.

IMHO & AFAIK