Егоров АлександрНе Hibernateесть и другие варианты. В них бизнес-объекты не зависят от структуры БД и DAL(можно использовать и хранимые процедуры), это позволяет сочетать достоинства двух крайних,горячо здесь обсуждаемых, вариантов.
Именно такой вариант и предлагается. Просто его почему-то упорно называют "вся бизнес-логика в СУБД". :)

Нет. Это другой крайний вариант с другим люфтом. Взять хотя бы проверку на constraine c выводом вменяемых сообщений пользователю.

Егоров АлександрНе Hibernateесть и другие варианты. В них бизнес-объекты не зависят от структуры БД и DAL(можно использовать и хранимые процедуры), это позволяет сочетать достоинства двух крайних,горячо здесь обсуждаемых, вариантов.
Именно такой вариант и предлагается. Просто его почему-то упорно называют "вся бизнес-логика в СУБД". :)
Помимо ORM есть вариации на тему Active Record. В них БО не зависит от структуры БД, полностью скрыта работа с ней, предоставляются только нужные интерфейсы. Нет танцев с бубнами для маппинга ORM, можно работать с процедурами, распределить БЛ по двум слоям.
Совсем другой вариант . Еще один экстремист, ему даже мало одной БД.
Вариантов много.

Егоров АлександрBogdanov AndreyВы хотите сказать, что ОО-системы более затратны в поддержке? Можете привести статистику, или какие-то разумные доводы кроме своего имхо?
Основная доля затрат на поддержку - это стоимость модификаций и модернизаций. ОО-подход более адаптивен и гораздо лучше переваривает изменения. Несомненно наличие грамотного архитектора и централизация всех изменений сильно упрощают модификацию и для не ОО-систем. Но как раз потребитель не имеет грамотных архитекторов, а желает выполнять некторые модификации своими руами (так как чужие слишком дороги).
Вобщем-то я имел ввиду только системы, у которых вся бизнес-логика написана на объектно-ориентированном ЯВУ и работает с РСУБД через ORM не используя возможности этих СУБД по обработке данных. Статистику привести не могу. Но мо мнение авторы подобных ОО-систем поколебать не смогли. :) На пример необходимых изменений в "разделенной" системе, получен пример необходимых изменений в ОО-ситеме. Это совпадает с моим мнением. Ибо более затратные телодвижения разработчика по модификации бизнес-логики естественно будут переложены на кошелек заказчика. :) Обратных примеров приведено не было ни одного. Спорным вопросом остается также совокупная стоимость железа, требуемая для работы разных систем. Включая затраты на его содержание, естественно.

Боюсь, что мы действительно пытаемся спорить о совершенно разных системах. Вернее, как заметил Iscrafm, о системах совершенно различного применения.
Правильно, системы бывают разные. Валидация данных в удаленной БД совершенно неприемлема(лишний трафик и существенные задержки). Подсчет в примере совершенно не учитывает варианты, когда после проверок БД говорит - не шмогла. Помимо этого, за счет кеширования ООП можно убрать некоторые шаги и обращения к БД.

Bogdanov AndreyЕгоров АлександрВобщем-то я имел ввиду только системы, у которых вся бизнес-логика написана на объектно-ориентированном ЯВУ и работает с РСУБД через ORM не используя возможности этих СУБД по обработке данных.МЫ вроде бы не недостатки каких-то конкретных систем здесь обсуждаем, а некотрые общие архитектурные принципы. Можно найти огромное количество плохих систем построенных на любом архитектурном принципе. Но само наличие таких систем не доказывает, что принципы плохи. Тут надо либо статистикой оперировать, либо логические доказательства приводить.
За доказательствами далеко ходить не нужно. Достаточно рассмотреть для сравнения не идеальный вариант, а с ошибками ввода, которые могут повторяться. Учесть валидацию, контроль на дубликаты и добавить необходимость подсчета итоговой суммы хотя бы для 10 строк. Все это проще, быстрее, внятней для пользователя, лучше делать на клиенте с меньшей нагрузкой на БД.

Егоров АлександрНе Hibarnateа мой скромный взгляд, пример для показа преимуществ выноса БЛ в БД выбран весьма неудачно. Валидацию,подсчет агрегатов, проще и удобней делать в ООП, не говоря уже о том, что процесс приема заявки может быть достаточно сложным. Добавьте хотя бы простую проверку на дубликаты в деталировке, рассмотрите крайние случаи, цифры будут не в пользу БД.Ну, не знаю. По условию задачи данные для проверки все были в БД, поэтому и проверку проще было сделать в БД. Проверка состояла бы из единственно запроса. Дубликаты и агрегаты я бы тоже делал не в БД, а в форме ввода.
Если даже запрос на валидацию единственный, он достаточно мутный, если выводить подробную информацию для пользователя. Вместо моментального показа неверно введенного значения с пояснением, выводим кашу со списком ошибок, пользователю нужно запомнить все, найти нужное место, исправить, еще раз подтвердить ввод. Позиций может быть много, процесс растянется до бесконечности.