Я чтобы поддержать разговор чиста :)

kilaviпричины?
1. легкость масштабирования
2. на ОО языке, проще создавать большие системы
3. управление исходниками, для managed языков есть прекрасные средства рефакторинга и удобные IDE среды(у нас система из 3000 хранимок - это просто Ж)
4. безболезненная смена СУБД
5. увеличение скорости разработки приложения

1. Масштабирование количеством серверов достигается при любом способе - хоть многозвенка, хоть субд, тупое увеличение количества железа
2. Системы какого типа? Клиентские приложения - да. Работа с данными - это с чего на оо лучше работать с таблицами? ;)
3. Для клиентских приложений - да. Какую супер-систему нужно, чтобы писать ХП - не пойму. Причем тут кол-во ХП - вы сразу все правите в одном сеансе? Или сразу все на экран хотите вывести? ;)
4. Миф - никто ни разу не делал этого, более того, система не использует все тонкости СУБД, а потому заранее тормознее и неуклюжее, причем намного.
5. Каким образом? Добавляя дополнительное звено, скорость только уменьшается

В общем, эти вопросы давно разобраны в паре тдлинных топиков и серьезных доказательств по ним многозвенщики не смогли привести.

kilaviДа и хорошо спроектированную программу написанную на языке высокого уровня, с четкой структурой классов на порядок легче понять, кроме этого хорошо спроектированную программу на порядок легче оптимизировать, таким образом, если вдруг и где возникнуть затыки, никто не мешает перенести этот момент в БД.
Так нужно хорошо проектировать систему независимо от того, как ее пишут. :) Тогда и понять можно

kilaviЛично для меня священной войны здесь нет, все зависит от конкретного проекта, но уклон в сторону сервера приложений со временем все равно неизбежен имхо. Да и вообще лично у меня нет желания заниматься процедурным программированием, когда есть ООП. Сейчас начинаем новый большой проект, чистая база, с какой радостью натравлю туда ОРМ, и буду работать с объектами.
Ну и в чем смысл объектов?
Может просто - как и показали те топики - знаний в СУБД не хватает? Тогда конечно - разбираться в селектах/апдейтах/plsql/tsql ни к чему современному программисту, лучше перенести все данные на клиента и там с помощью паскаля или с++ делать свою СУБД Но зато какие понты - не какая-то там к-с, а "распределенная многозвенная система с возможностью масштабирования и т.д. и т.п.", заказчеки аж писчат, когда узнают название, правда потом воют, но это уже другая история. :)

===========

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

ЗЫ Интересно, а что же такого нельзя сделать на PL/SQL? Я думал, что уж теперь то на нем можно делать все, что угодно (учитывая то, что было раньше), особенно по сравнению с TSQL. В Оракл внутрь СУБД воткнули по-моему все, что только бывает. Или это страшная тайна? :)

-- Tygra's --
Мои фотогалереи тут и тут

2 iscrafm
Ну у меня сейчас нет таких потребностей для работы с разными СУБД во внутренней системе. Потому навскидку могу предложить либо делать коннект этой формы к другой СУБД прямо из приложения, либо через линкед сервер уже используемой СУБД. Но если подумать, можно и что-то другое наверное, но пока нет надобности.

Другая система, другой вариант, уже обкатанный - ходить через вебсервисы. Клиент идет на вебсервис и дергает нужный метод, а уж тот дергает то, что ему там прописано, хоть СУБД, хоть другой сервис. Вроде как также быстро делается.
Только не надо говорить, что это уже многзвенка :) Это коммутирующий слой без всяких вычислений и бизнес-логики, считайте его заменителем ADO :)

----------
Но получается, что вычислений тут нигде нет, бизнес-логики в доп звене нет, это к теме топика мало относится :)

-- Tygra's --
Мои фотогалереи тут и тут

iscrafmнеправильные у Вас представления о многозвенке. Web-сервер, на котором живут сервисы - обычный сервер приложений. Зовут его просто по другому.
Это смотря с какой стороны посмотреть. Тут вот люди считают, что апп-сервер - это обязательно в нем бизнес-логика и обработка данных, что никаких других серверов приложений не бывает.
У вас вроде не такой, у меня тем более :)

авторугу. А что тогда PHP, Perl,Java и прочие скрипты там делают. Заменяют ADO по Вашему.
Скрипты там являются клиентским приложением - они заменяют дельфи, с++ и т.д.
А АДО они заменяют мне - я же не хожу на html-страницы для того, чтобы дернуть сервис :)

авторПовторюсь только.. это никак не исключает реализацию бизнес-логики в СУБД.
В этом то и вопрос.

-- Tygra's --
Мои фотогалереи тут и тут