carperПодобъем предварительные итоги:
...
Так?Многое из сказанного верно, но, на мой взгляд, имеет малое отношение к вопросу выбора места реализации бизнес-логики. Особенно учитывая то, что практически все приведенные преимущества и недостатки сразу же дезавуированы.
Я бы рассматривал вопрос в несколько иной плоскости. Архитектуру надо выбирать исходя из эффективности решения большинства задач, и предусматривать то, что из любых правил будут исключения. Буду исходить из предположения о том, что система будет жить долго, активно модифицироваться и дорабатываться. В этом случае архитектура должна обеспечить как минимум две вещи - простоту интеграции (с учетом перспектив развития методов интеграции) и простоту модификации.
1. Интеграция. На данный момент времени лидирующей технологией в этом направлении, кажется, является SOA. Не буду обсуждать перспективы (это где-то в соседнем топике), но сейчас это востребовано. И тут без сервера приложений жить неудобно. То есть трехуровневая архитектура - почти неизбежный выбор. Несомненно, даже при наличии сервера приложений родные клиенты могут ходить в базу напрямую, но мне не кажется это разумным. Кроме того, сейчас есть огромная мода (хотя на практике это мало кому надо) на web-интерфейсы. В рамках этого пункта можно рассмотреть высказываение с которым трудно согласиться:carperЗа одним НО - число приложений, умеющих работать с СУБД, на несколько порядков больше, чем с нашим сервером приложений. Если придумывать собственные пртоколы для интерфейса сервера приложений, то это может быть и верно, но есть типовые протоколы. Сейчас систем, умеющих вызывать, например, веб-сервисы ничуть не меньше, чем умеющих присоединяться к базе данных.
2. Простота модификации. Тут стоит отметить, что лучшей документацией всегда является код. Поэтому стоит расчитывать на то, что те, кто будут что-то модифицировать в первую очередь попытаются разобаться в коде. Чем меньше языков использовано при написании кода, тем легче будет разобраться. Дополнительной сложностью при размазывании бизнес-логики на несколько уровней является и то, что почти наверняка возникнет потребность из элемента, реализованного на нижнем уровне, вызвать элемент, реализованный на верхнем. Изящно решить эту проблему не всегда удается.
Исходя из этого стоит стремиться всю бизнес-логику реализовать в рамках одного слоя. По моим ощущениям это можно сделать всегда. Правда изредка это может быть не самым эффективным (в основном с точки зрения использования вычислительных ресурсов) решением. Но таких случаев очень мало и не стоит эти исключения возводить в правило.
Ну и если уж делать бизнес-логику в рамках одного слоя, то надо решить что это будет - СУБД или СП. Основным аргументом тут будет, наверное, квалификация разработчиков. Если большая часть прикладных программистов - "базисты", то стоит выбрать ХП. Если "жависты", то СП. Если же абстрагироваться от квалификации, то я бы рекомендовал СП - во-первых, языковые средства для СП более выразительны (не стоит сбрасывть со счетов ООП), а во-вторых, по-моим ощущениям, задач которые решаются на СП эффективнее, чем в БД больше, чем тех, что эффективнее решаются в БД. Хотя подавляющее большинство задач решаются одинаково эффективно. Естественно, специфика конкретной задачи может сместить акценты, я ориентировался на некое собственное представление о типовой учетной системе.

carper
Правда изредка это может быть не самым эффективным
Изредка?
Почти в любом приложении подавляющая часть всего кода тривиальна и надо постараться, чтобы написать его неэффективно. Да и большая часть функционала обычно крайне нетребовательна (обычно десяток элементарных справочников на одну серъезную операцию :) ). Другое дело, что крайне малая нетривиальная часть всегда наиболее заметна.

carper
Меня многое смущает, но прежде всего то, что одной из идей, как мне кажется, 3-х звенного приложения является разделение сфер ответственности, например, не должна СУБД общаться с клиентами.

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

carper
Никто в сложном приложении не отменял, например, модульности разработки, но тогда возникает вопрос - и что плохого в том, что часть модулей будет реализована в другом месте, специалистами своего профиля?Тут главный вопрос в том, что мы считаем модулями. Мне кажется, что модуль должен включать некоторую относительно замкнутую часть функционала. Модель данных сама по себе мало кому-нужна без бизнес-логики. Посему и рассматривать просто данные, как отдельный модуль - нелогично.
Но если мы выделили какие-то модули, то у них может быть разное место реализации бизнес-логики.

carperКто сказал, что перенеся логику на СП мы сможем отказаться от спецов по работе с БД?Я такого точно не говорил :)

carperЯ описал свое видение БЛ на СУБД просто как попытку уйти от парадигмы работы с таблицами на парадигму работы с примитивными операциями, скрывающими внутреннюю структуру базыЯ об этом писал в ответ web_fox - вы предпочитаете в бизнес-логике оперировать нереляционной моделью данных. Это нормально. Но я считаю, что эту нереляционную модель удобнее реализовывать не средствами реляционной БД, а другими средствами.

carperВообще-то я о том же. Так ХР "добавление пользователя" вполне себе замкнуто знает имена таблиц и процедур задействованных при этом самом добавлении, предназначенных для проведения целостной транзакции.Да. каждую процедуру можно считать модулем, но это не удобно. Цель разбиения функционала на модули - сделать количество взаимодествующих элементов на каждом уровне абстракции поддающимся осмыслению. Если у нас всего 100 программных единиц, то разумно иметь 10 модулей по 10 программных единиц в каждой. Для бОльших систем и модули стоит рассматривать более крупные. В какой-то момент стоит вводить уже "трехуровневую" классификацию подсистема-модуль-элемент и мириться с дублированием функционала в разных подсистемах ради того, чтобы сохранить управляемость.
Посему рассуждая о "модулях" я все-таки имею ввиду нечто большее чем один класс или одну процедуру.
carperПосле чего вызывает одноименную ХР.
Никакого дублирования ни логики ни поведения здесь вроде как нет.Естественно так делать можно. Другой вопрос - нужно ли. Если эта одноименная ХП вызывается ровно в одном месте, то возникает вопрос - зачем "разрывать функционал" - с равным успехом можно все сделать на СП и код вряд ли станет менее прозрачным.

Часть аргументов, конечно надумана, c некоторыми согласен. Вопрос в том, пересилят ли эти аргументы отрицательные стороны разделения логики на разные слои.
Основные, на мой взгляд, отрицательные стороны - сложность анализа кода и проблемы с управлением изменениями. По своему опыту могу сказать, что проблема синхронизации изменений и "выставления" синхронизированных патчей многими компаниями до сих пор толком не решена - постоянно приходят обноления модулей с забытыми ХП или наоборот. Не могу сказать, что решений не существуют, но они зачастую административного характера, а следовательно крайне ненадежны. Собственно одним из существенных аргументов при начале разработки собственного фреймворка очень часть указывается простота (правда большинством недостигаемая :) ) синхронизации изменений слоев.

carperВо-первых, уже упоминалась проблема производительности.
Да, не всегда и не везде это хоть как-то проявится, но если она есть, то лучше уж "разорвать".Ну тут лучше разорвать именно тогда когда надо, не возводя в правило.

carperВо-вторых, когда возникнет вопрос использования не "в одном месте", что делать?
Мне кажется, что XП могут дать более универсальный ответ на этот вопрос.Не только ХП допускают повторное использование.

carperВ-третьих, если надо будет поддерживать несколько СУБД, НЕ поступаясь даваемыми ими преимуществами, то, при реализации низкоуровневой логики на ХП, изменения на СП будут минимальными, зачастую просто сведутся к изменению синтаксиса вызова ХП.А то, что все ХП придется переписывать вы забыли?

carperВ-четвертых, легче найти грамотного DBA, разбирающегося в том же PL/SQL, чем в C#.Согласен, но зачем DBA должен разбираться в C#?

carperВ-шестых, использование ХР позволяет в полной мере задействовать средства безопасности СУБД.Все верно, но должен сказать, что почти все СП, которые я видел использовали для хода в СУБД одну и ту же учетную запись. Так что возможность осталась неиспользованной.

carperВ-седьмых, что если мы придем к выводу, что для привлечения заказчиков, нам надо бы сделать наше приложение, написанное на Delphi, например, кроссплатформенным, хотя бы потому, что тогда ему придется платить деньги только за наш СП, а не за Windows ?

ХР снимут часть проблем по переходу на другую платформу.Чуть выше вы писали, что ХП помогут при смене СУБД, теперь, что они помогут при смене СП. Немного противоречиво :)

carperМне просто кажется, что повторное использование ХП проще, чем повторное использование API СП, хотя бы потому, что API ХП понимает гораздо большее число приложений и не надо городить ужас с передачей всего и вся через XML и прочую хрень.Я тоже больше разработчик СУБД, посему понимаю ваши слова об ужасе, но, поверьте, вы не совсем правы. Просто вы (в общем-то, также как и я) плохо знакомы с технологиями взаимодействия приложений. Но например, мне кажется, что из Visual Basic com-объект подцепить проще, чем ХП.

carperНи в коей мере не забыл. Я пытался сказать, что дописать сами ХП может оказаться проще, чем дописывать соотв. логику на СП.И опять же это вопрос квалификации имеющихся разработчиков. Где-то выше я уже писал, что очень часто основной причиной выбора языка реализации являются превалирующие квалификации в группе разработчиков.

carperавторСогласен, но зачем DBA должен разбираться в C#?
Затем, что я сомневаюсь в том, что СП написан на PL/SQL.Пока не улавливаю связи. DBA занимается своими вопросами - зачем ему лезть в код СП - мне не понятно. Если он видит, что в базу данных приходят "плохие" запросы, то он должен дать рекомендации по их "улучшению". В код СП для этого лезть не надо.

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

carperМы еще не коснулись темы кривости ORM, например, в Hibernate ...К сожалению, обсуждение этой темы я поддержать не могу, ввиду недостаточного опыта работы с Hibernate, да и считаю, что в рамках данной темы это оффтопик.

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