Почитал-почитал и решил высказать вот такое видение.

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

Начнем с удобства использования.
По моему нет никакой разницы в том, используют ли разработчики для доступа к данным SQL (т.е. интерфейс доступа описан в виде набора представлений и хранимых процедур) или внятно описанный C++-интерфейс (Java, 3GL ... ). Ключевым моментом здесь является "ясно и полностью описанный". Именно проблемы с описаниями зачастую и приводят к ситуациям, когда SQL-доступ кажется более удобным (тут по крайней мере есть возможность самому в чем-то разобраться, особенно когда есть доступ к исходным текстам SQL-процедур). Таким образом, оказывается, что требования к документированию могут ужесточиться, если мы отказались от реализации бизнес-логики в хранимых процедурах.

Теперь о производительности.
Всегда следует понимать, что отделяя бизнес-логику от данных мы с одной стороны уменьшаем требования к серверу БД, но вовсе не уменьшаем требования к полосе пропускания между ним и сервером БЛ. Если БЛ реализуется в рамках той же СУБД в виде хранимых процедур, то до определенного момента выйгрыш от такой реализации будет очевиден - вся тяжелая нагрузка ляжет на один сервер, для которого просто нужно выбрать подходящее железо. Но при росте нагрузок вопрос увеличения производительности может стать ребром. Для систем большого масштаба четкое отделение БЛ от данных с возможностью разнесения их по разным серверам является обязательным требованием (тут надо помнить о том, что отдельный сервер для БЛ вовсе не означает отказа от хранимых процедур).

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

Выводы.
ХП удобны для небольших систем и позволяют сократить затраты на разработку.
Системы с ХП потенциально труднее переносимы на другую платформу.
Нет никаких принципиальных отличий фундаментального характера между системами с БЛ в ХП и без ХП.

Александр Гoлдун Alexey Rovdo
Разумеется, реализуя БЛ в рамках хранимых процедур мы неизбежно привязываемся к той платформе, на которой эти хранимые процедуры пишутся.
Переход на иную платформу в этом случае будет практически невозможен (очень дорог). Попытки написания каких-то полумультиплатформных ХП в таком контексте я даже не рассматриваю (глупая затея). С этим ясно.

Не очень ясно. Можно подробнее разъяснить?
Что понимается по термином "Мультиплатформная ХП"? Если это универсальный и одинаковый для всех серверов текст типа:
CREATE PROCEDURE .....
BEGIN
....
END
тогда действительно глупая затея. Если ли же под этим понимается, например, процедура OrderClose, которая имеет четкий набор параметров, выполняет документированные действия и вызывается одинаково для всех серверов, то почему бы и нет? При этом код внутри может отличаться для разных серверов с учетом особенностей, синтаксиса и т.п. Но для клиентского приложения или сервера бизнес-логики эти различия нивелируются в стандартный вызов процедуры. Чем плохо? IMHO это улучшает переносимость системы в целом, хотя и требует доп. затрат на написание процедур под разные сервера.

Вы поняли меня вполне правильно. И я полностью с вами согласен по первому варианту. Самое забавное, что я действительно встречал людей (уровня технического руководителя проекта), которые на полном серьезе пропагандировали именно первый вариант, т.е. предлагали писать полностью универсальные решения (где отличия обуславливались бы только незначительными изменениями синтаксиса, обусловленными требованиями конкретной СУБД).
Но вот по второму варианту я с вами не вполне согласен. Плохо тем, что под каждую СУБД вам прийдется переписывать ХП. Если у вас стоит задача поддержки множества различных СУБД, то правильнее будет реализовать свой промежуточный слой бизнес-логики однократно (например, на базе EJB+JDO или на проприетарной платформе). Да, при этом может пострадать производительность, но значительно облегчится сама разработка и развитие системы.