Интересное какое обсуждение, непонятно, правда, почему столь достойные доны общаются на таких повышенных тонах. Я вот немного прикинул выгоды от работы с OEBS (подойдет как пример трехзвенки?) за последние пару лет и вот что получил.
1. Из всего парка компьютеров (более 300) ни один не был списан по причине нехватки ресурсов для запуска OEBS. Что интересно, ресурсы ПК растут, а функционал рабочих мест меняется несильно, как пользователи не умели в Office 95 работать, так и в 2003 не умеют.
2. Тяжелые отчеты из клиент-серверной версии Discoverer на многих машинах просто не работали, они же, перенесенные на сервер приложений, работают везде. Обращаю внимание, что сами рабочие книги не изменились.
3. Все задачи, важные для бизнеса, но не имеющие прямого отношения к базам данных, такие, как обмен по FTP, почте, генерация данных для внешних систем и т.д., были вынесены из хранимых процедур и пакетов и реализованы на сервере приложений, производительность выросла в разы, нагрузка на сервер БД уменьшилась. Опять же подчеркиваю, функционал этих задач не изменился, а даже улучшился.
4. Про администрирование рабочих мест даже говорить нечего. Вопросы типа «какая версия программы», «а где эта dll-ка», «почему принтер не установлен» и т.д. отсутствуют по определению.
5. Как выяснилось, многие конфликтные ситуации, которые возникали в работе одновременно работающих процедур, успешно решаются на уровне менеджера запросов. При этом природа этих задач совершенно разная. Согласитесь, значительно проще грамотно настроить наборы запросов/отчеты, чем разбираться в разных способах блокировок всего и вся. Тривиальный пример: нужно избежать одновременного обмена по FTP и загрузки данных разных форматов в разные модули. Часть программ работают по факту появления файлов, часть по расписанию, и никто никому не мешает. Естественно, когда анализ части конфликтных ситуаций из кода программы вынесен, она упрощается, а это и снижает требования к разработчику, т.е. не надо держать гения, который знает на зубок все pl/sql-пакеты, достаточно грамотного сотрудника для решения конкретной задачи. Для управления проектом это очень важно.
6. Вопросы надежности рассматривать не буду, но система работает в режиме 24*7 при минимальном администрировании.
Короче говоря, выигрыш при эксплуатации подобной системы имеется, для определенной ниши клиентов он может быть очень даже существенным.

OA User
1. Из всего парка компьютеров (более 300) ни один не был списан по причине нехватки ресурсов для запуска OEBS. Что интересно, ресурсы ПК растут, а функционал рабочих мест меняется несильно, как пользователи не умели в Office 95 работать, так и в 2003 не умеют.

а причем тут СП ? это же не 1С где логика же не на клиенте.
[/quot]
При том, требования к ПК конечных пользователей минимальны, и это не зависит от функций этого пользователя в системе, соответственно, срок эксплуатации ПК в рамках этого решения дольше, а поддержка - дешевле. Это, правда, важно для тех, кто платит, а не программирует.
systemR
вы перенесли репортера с клиента на СП, понятно что на клиенте он тормозил, перенесли бы формирование отчетов в субд, было бы на порядок быстрее.

Discoverer - это ROLAP, ему нужен ресурс на клиенте для работы с данными, чтобы строить требуемые разрезы, и больших выборок данных тут не избежать.
systemR
OA User
3. Все задачи, важные для бизнеса, но не имеющие прямого отношения к базам данных, такие, как обмен по FTP, почте, генерация данных для внешних систем и т.д., были вынесены из хранимых процедур и пакетов и реализованы на сервере приложений, производительность выросла в разы, нагрузка на сервер БД уменьшилась. Опять же подчеркиваю, функционал этих задач не изменился, а даже улучшился.

теперь чтоб добится непрерывности бизнеса вам прийдется кроме дублирования субд еще дублировать СП, пропгрейдить железо для субд было бы гораздо эфективней и дешевле.

мы разнесли нагрузку по серверам и это оказалось эффективнее, чем просто наращивать мощности сервера БД. Сейчас сервер БД занят собственно обработкой данных, а СП - прочими задачами. Наверно, Вы не будете спорить, что мониторить и планировать однотипную нагрузку проще?
systemR
OA User
4. Про администрирование рабочих мест даже говорить нечего. Вопросы типа «какая версия программы», «а где эта dll-ка», «почему принтер не установлен» и т.д. отсутствуют по определению.

такие вопросы могли появлятся только по незнанию. клиент кроме отрисовки данных ничем заниматся не должен.

Я вроде не про отрисовку данных писал. Кстати, в моем примере, клиент только этим и занимается.
systemR
OA User
5. Как выяснилось, многие конфликтные ситуации, которые возникали в работе одновременно работающих процедур, успешно решаются на уровне менеджера запросов. При этом природа этих задач совершенно разная. Согласитесь, значительно проще грамотно настроить наборы запросов/отчеты, чем разбираться в разных способах блокировок всего и вся. Тривиальный пример: нужно избежать одновременного обмена по FTP и загрузки данных разных форматов в разные модули. Часть программ работают по факту появления файлов, часть по расписанию, и никто никому не мешает. Естественно, когда анализ части конфликтных ситуаций из кода программы вынесен, она упрощается, а это и снижает требования к разработчику, т.е. не надо держать гения, который знает на зубок все pl/sql-пакеты, достаточно грамотного сотрудника для решения конкретной задачи. Для управления проектом это очень важно.

нечего пускать студентов к системе, если вы не сожете сериализовать транзакции ***

Если серьезно, то работа с СУБД - это ведь только часть информационной системы, а есть еще множество задач в рамках той же системы, которые можно значительно эффективнее решить не средствами СУБД. Чем в этом случае плох сервер приложений? Это очень удобная среда для интеграции такого рода задач.

P.S. По администрированию - пока получается сочетать все в одном человеке.

отредактировано модератором

systemRнеправда, discoverer это ROLAP клиент . когда-то давно у оракла был продукт oracle express - вынесеный вне субд OLAP сервер, но такая архитектура просела при нормальных нагрузках и теперь у оракла OLAP это опция субд, т.е. там где и должна быть. к стате очень яркий пример.

oracle express здесь не обсуждается. Ок? Oracle Discoverer - это ROLAP-клиент, может работать как и в клиент-серверной архитектуре, так и в трехзвенной. Для построения временных кубов, таблиц, как угодно, в первом случае этот клиент будет использовать ресурсы ПК, во втором - ресурсы сервера приложений. Теперь понятнее?

systemR
поэтому у вас и принимаются такие интересные решения, ваш человек наверно и линукс знает и видовс и субд администрит, и в джаве может покапатся и все это наверника делает одинаково высокопрофесионально.
нет, человек занимается только администрированием СУБД и в значительно меньшей степени администрированием СП. windows, linux, java и прочие страшные слова к его служебным обязанностям не относятся.