avariceМы с коллегами планируем разработку трёхзвенного enterprise-приложения, и возник у нас спор - где лучше реализовывать бизнес-логику?

Naroto повидало много трехзвенных решений. Коликчество решений наверное разделится пополам. На общий взгляд наверное всё зависит от подготовки персонала. Если персонал никогда ничего не писал в SQL формате - то реализация бизнес логики (под давлением начальствующего архитектора) на стороне СУБД приведёт к совершенно безобразной производительности. Если же база данных построена изначально грамотно - под спецификацию заказчика и в команде есть грамотный DBA то реализация бизнес логики трёхзвенки методами ORM или любыми другими современными методами - одно удовольствие. Но Naroto лучше удалится пожелав Автору хорошего настроения. И очень хорошего архитектора.

mcureenabНе скажу за всю Одессу. Скажу за Оракл..
_modА на формсе все равно где - и там и там pl/sql.

Naroto хотело бы обратить внимание на повторяющися посты так называемых Ораклистов. Дело в том что язык PL\SQL - язык формально четвёртого поколения. Все языки четвёртого поколения имеют существенное преимущество в разработке приложений которые интересуют нашего TS. Огромный их недостаток - они часть системы поэтому приобрести и использовать и компилировать программы в среде этих языков стоит больших денег. Если же пользоваться стандартным набором общедоступных языков третьего поколения (C\C++\C#, VB(.NET), Java\J#, and many frameworks) и SQL от поставщика базы данных... удешевление налицо, но преимуществ централизованного кодирование вы не увидите.

На всяк случай вот справка о некоторых языках четвертого поколения.

mcureenabНе понял, в чём подвох. .

Да, Naroto следовало бы подчеркнуть специально для автора топика что производство ПО на продажу и реализация какого-то индивидуального проекта - существенно меняет дело. Допустим наш Топик Стартер с коллегами планирует разработку трёхзвенного enterprise-приложения на продажу и возник у них спор - где лучше реализовывать бизнес-логику. Этот спор сразу бы упёрся в платформу и среду разработки . Но Naroto не уверено, что у них там есть такое изыскание. Скорее всего и платформа и среда разработки архитектурно определены. Naroto думает, что это не Oracle. Некоторые коллеги Ораклисты советуют этот замечательный продукт. Naroto предупредило о дороговизне и сложности в реализации. Скорее всего всё будет сделано на мелкомягкостях ввиду доступности и ширпотребности. Naroto обратило внимание TS что им понадобится хороший дезайнер ну или архитектор. Если коллеги топик стартера знают или уже писали SQL - проблем не будет разместить бизнес логику на стороне СУБД. Ежели никто не имел опыта написания ХП то всё должно писаться на сервере приложений в формате языка 3GL (C++\C#, VB.NET, Java etc) + нужен хороший DBA чтоб понял где будет зарыта собака. И обеспечил безопасность по мере внедрения системы. Вот и фсё Спасибо за внимание ...

mcureenabбизнес-логику удобно размещать в ХП (.... и данные не надо передавать из СУБД в сервер приложений и назад).

Naroto Улыбнуло

Уважаемый mcureenab, Да хранит Ваш Код всемогущий Один. Всё Вы говорите разумно, вот за исключением маленькой дезинформации. Данные надо бы всёжтки передавать из базы к интерфейсу и обратно. Иначе что за приложение получится - Самодостаточно Складируемое (OLAP)? Так и в нём когда никогда поковыряться надобно.А ковыряние -это передачка данных. Из СУБД в Сервер Приложений (для передачи в интерфейс) и назад. Мы же определились что прямого доступа у клиента к базе быть не должно...
Или Naroto ошибло?