DPH3barrabas
Нужны еще как.
Помимо производительности еще и облегчение администрирования, все права даются на хранимки, а напрямую с таблицами клиент работать не должен. Да и изменение логики проходит проще - без сборки новой версии клиента, а просто заменой логики хранимки на сервере.
Это ты опять про двузвенки говоришь, где причины появления хранимок вполне понятны (как эмуляция application layer).
Да сколько-угодно-звенки!
С точки зрения сервера, управляющего БД, все что к нему обращается снаружи - клиент. И если клиент читает/меняет данные в БД через хранимые процедуры, это:
- во многих случаях, сильно ускоряет работу системы в целом,
- упрощает обеспечение целостности и непротиворечивости данных,
- сильно упрощает сопровождение и развитие системы;
- про разделение доступа к объектам бд тут уже много писали...
DPH3[А вот в трехзвенках ничего из этого уже не нужно...
Ну, тогда dbf-ники на новелловском сервере лучшая БД для вас

DPH3Бизнес-логика в большинстве приложений (даже очень простых) не сводится к DML. А это значит, что реально таки пишется средний слой, только не на универсальном языке, а на каком-нибудь T-SQL. Ну и все велосипеды, которые обычно уже есть в универсальных платформах - придумываются с нуля.
Если на T-SQL пишется также, как на процедурных языках, то таки да! Получается ужас
Но любым инструментом надо уметь пользоваться...

ЛПbaracs
И если клиент читает/меняет данные в БД через хранимые процедуры, это:
- во многих случаях, сильно ускоряет работу системы в целом,
- упрощает обеспечение целостности и непротиворечивости данных,
- сильно упрощает сопровождение и развитие системы;
- про разделение доступа к объектам бд тут уже много писали...
В случае, если у СУБД ровно один клиент (а это именно случай многозвенных приложений) - Ваше высказывание неверно по всем пунктам (по некоторым пунктам оно неверно и в случае многих клиентов)
А поподробнее?

DPH3baracs И если клиент читает/меняет данные в БД через хранимые процедуры, это:
- во многих случаях, сильно ускоряет работу системы в целом,

Э, в каких? Ну, кроме серверного курсора по миллиону строк, который, нужен крайне редко (а лучше бы - никогда).
Когда приложение вытягивает из нескольких таблиц по нескольку сотен тыщ строк, чтобы внутри себя их перелопатить и выбрать из этой кучи пару десятков нужных.
DPH3baracs
- упрощает обеспечение целостности и непротиворечивости данных,

Как?
Выполняя необходимые проверки, когда они требуют обращения ко множеству таблиц, не "вылезая" с сервера.
DPH3baracs
- сильно упрощает сопровождение и развитие системы;

Ой, а тут - как? Как отдать в тестирование сборку промежуточного сервера - я знаю.
А вот как отдать в тестирование структуру БД....
Я уж молчу про невозможность рефакторинга в SQLе, неразвитость (это мягко сказано) IDE, убогость языковых средств и т.д.
А БД - это не модуль.
Она плавно развивается, как живой организм. ХП и представления, как раз и помогают смягчать последствия болезней роста.
Ох чую, на разных языках мы говорим
DPH3baracs
- про разделение доступа к объектам бд тут уже много писали...

Э, а что, у вас каждый пользователь системы имеет отдельную учетную запись в БД? И авторизуется прямо в БД?
А разновсякие есть Жизнь, она разнообразна...
DPH3baracs
Ну, тогда dbf-ники на новелловском сервере лучшая БД для вас
Ну, моя любимая БД - это IBM DB2. Самый развитый SQL и осознание потребностей трехзвенок :)
К сожалению, нет возможности осознать всю крутизну...