Коллеги, наткнулся на такую вот статью на хабре Где наша бизнес-логика, сынок?
У меня на работе завязался нешуточный спор по теме, что лучше:

• Вся бизнес логика реализована в приложении на сервере приложений (IBM WebSphere);
  
• Часть бизнес логики реализована на уровне БД в хранимых процедурах, приложение на сервере приложений используется, в основном, в качестве GUI (view)[четырехзвенка или недотрехзвенка?];
  

Дополнительно стоит добавить еще такие моменты:
У нас на работе существуют две основные СУБД: Oracle - для сторонних систем и IBM DB2 - для систем, разрабатываемых своими силами. Еще есть SQL Server, но его не будем рассматривать.
Нагрузка на БД целевой системы - порядка 150000 запросов в сутки, количество пользователей, работающих с веб-интерфейсом - порядка 20 сотрудников.
У меня вопрос к тем, кто сталкивался с подобным выбором:
Какой вариант будет предпочтительнее из приведенных ниже?

• Вся бизнес логика реализована в приложении на сервере приложений (IBM WebSphere), целевая СУБД - IBM DB2;
  
• Часть бизнес логики реализована на уровне БД в хранимых процедурах, приложение на сервере приложений используется, в основном, в качестве GUI, целевая СУБД - IBM DB2;
  
• Вся бизнес логика реализована в приложении на сервере приложений (IBM WebSphere), целевая СУБД - Oracle;
  
• Часть бизнес логики реализована на уровне БД в хранимых процедурах, приложение на сервере приложений используется, в основном, в качестве GUI, целевая СУБД - Oracle;
  

Я сварщик не настоящий, но... Из некоторых проектов вынес следующее:
1. Логика на хранимых процедурах - это дешево (в разработке), быстро (в исполнении) и дает возможность задействовать весьма приятные фишки от разработчиков СУБД.
2. Часть логики на хранимых процедурах, часть на сервере приложений - сплошные неудобства в документировании и страшный геморрой, когда дело касается развития системы через год-другой (когда большая часть "тех, кто помнит" уже разбежалась на другие проекты).

Соответственно, если надо дешево и сердито - вперед в хранилки. Если детище надо сопровождать и развивать - возможно, стоит потратиться на классическое разбиение.

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

P.S. 150к запросов в день и 20 активных пользователей - это мелочи. Любая из раскрученных СУБД такое (и не такое) осилит на раз.

Думаю, что лучшее место для таких обсуждений — sql.ru

Почему не рассматриваете SQL Server? Непонятно.

После 5 лет разработки ХП на Оракле, для простых систем настоятельно рекомендую рассматривать сначала более простые технологические связки, типа php + mysql.

Ну и это — покажите требования к качеству системы, тогда можно будет обсуждать более предметно.

Думаю, что лучшее место для таких обсуждений — sql.ru

- Денис, согласен, но все же решил выложить на всякий случай.

Почему не рассматриваете SQL Server? Непонятно.

- Не рассматриваю, т.к. у нас на работе существует нечто вроде стандарта организации, согласно которому

существуют две основные СУБД: Oracle - для сторонних систем и IBM DB2 - для систем, разрабатываемых своими силами.

- Это ограничение, на которое я, к сожалению (или к счастью), практически не могу сейчас повлиять. Кстати, на SQL server у меня развернуты модельные репозитории SPARX EA )))
Так что,

После 5 лет разработки ХП на Оракле, для простых систем настоятельно рекомендую рассматривать сначала более простые технологические связки, типа php + mysql

- к сожалению, не в моей компетенции.

Ну и это — покажите требования к качеству системы, тогда можно будет обсуждать более предметно.

- Вот что мне пока известно -

Нагрузка на БД целевой системы - порядка 150000 запросов в сутки, количество пользователей, работающих с веб-интерфейсом - порядка 20 сотрудников.

СУБД развернута на виртуальном сервере, параметры производительности пока что неизвестны, но известно, что при использовании СУБД DB2 периодически возникают "просадки" по производительности, чего не наблюдается, предположительно, при использовании Oracle со схожей конфигурацией платформы.
По поводу сравнения DB2 и Oracle наткнулся в форуме sql.ru на такую тему:
Oracle vs DB2
Вот такая фраза привлекла внимание:

у этих субд совершенно противоположные идиологии - оракл версионник, дб2 блокировочник

и ответ:

IBM-еры довольно много постарались для совместимости. Вплоть до того, что пустая строка может трактоваться, как NULL, а многие раньше блокирующие вещи теперь не блокируют. Нынешняя DB2 по совместимости... ну... примерно на уровне 9-го Oracle.

Читаю далее...

IMHO
Расположение бизнес-логики. Поддерживать и развивать логику проще, если она на сервере приложений. Меньше даунтайм, проще работа в ветками кода. Это не значит, что совсем нельзя держать логику в СУБД. Это означает, что получив на начальной стадии плюс в скорости разработки в СУБД вы потом просядете на поддержке.
Чем более сложным предполагается приложение тем больше доводов за хранение логики на сервере приложений.

Нагрузка на БД целевой системы - порядка 150000 запросов в сутки, количество пользователей, работающих с веб-интерфейсом - порядка 20 сотрудников.

Может я чего не понимаю, но это совсем небольшая нагрузка. Даже для серверов 15-летней давности это было весьма и весьма подъемно. В 2001 делал тестирование производительности для некоей системы. Без всякой оптимизации, да и с неудачной архитектурой. На слабых серверах система спокойно держала более 100 запросов в секунду (запросы на чтение). В 2008 по просьбе одного из сайтов проводили оптимизацию. Сервера также были не ахти (по тем временам). Несложной манипуляцией подняли производительность с 2 500 до 5 000 запросов в секунду. И никакого Оракла. И никакого кластера.
А 20 бизнес пользователей... Ну это 2000 год и низкопроизводительные FileMaker или Acces.
Наверное, я чего то не понимаю...

Thinkler, вообще голосовалка немного странная. Это архитектурное решение. А оно зависит от разных факторов. При этом на самом деле представлено два решения, где разница в сервере БД

Ещё можно задать вопрос в https://www.facebook.com/groups/software.architecture/

Эдуард, я объяснил причину ограниченности - наличия только двух вариантов СУБД, политикой компании.)))
Денис, спасибо за совет.