Некоторые подпрограммы на VBA напишут, положат их в ящик и назовут "хранимыми процедурами"...

2 ksv. Хранимые процедуры от просто процедур отличаются тем, что хранятся в откомпилированном виде на сервере СУБД, насколько я себе это понимаю. Все остальные процедуры не являются хранимыми. Это некие скрипты, которые отправляют запросы на СУБД, которые эта самая СУБД перед тем как выполнить, должна разобрать, интерпретировать и лишь затем выполнить. В итоге получаются дополнительные задержки просто потому, что скрипты эти - не являются хранимыми процедурами.
Триггеры - это разновидность хранимых процедур, отрабатывающих по определенным событиям. Но они тоже хранятся в базе данных в откомпилированном виде, и СУБД уже заранее проделала работу по составлению плана их выполнения. Использование триггеров и/или хранимых процедур является необходимым условием для перемещения бизнес-логики на сервер и получения тонкого клиента.
Трехзвенка - это здорово, с одной стороны. Но вопросы производительности и уменьшения сетевого траффика в ней могут быть решены, а могут быть и не решены или решены плохо. Между средним звеном и СУБД могут ходить толпами генеримые этим звеном запросы, и сервер будет тратить много ресурсов не только на их выполнение, но и на их оптимизацию и компиляцию. Среднее звено может возвращать оптимальный минимум информации на клиента, но между СУБД и средним звеном может ходить лавина данных, не передаваемая на клиента - это как, тонкий клиент, или не очень? И наконец, среднее звено может стать узким местом, если оно ограничивает пропускную способность системы, например, не имея возможности обрабатывать в многопоточной среде множество запросов от множества клиентов, организовывать очереди и т.п.
Так что ежели среднее звено чего-то там использует то, что не использует клиентская часть, то это еще бабушка на двое сказала - плюс это или минус.


ОФФТОП - лирическое отсутпление.

Не буду называть конкретно контору (если кого сильно интересует, что за контора, пишите в приват), но пыталась она у нас внедрить свою систему "Кадры". Работают там крутые-навороченные программисты, которые решили использовать трехзвенку для решения этой, в общем-то тривиальной задачи. Сбацали они сервер приложений с использованием COM+. В итоге куча глюков, просто море. Непонятные ограничения, произрастающие из особенностей именно этой трехзвенки. Просто установить это хозяйство - нужна спеца вызывать (да он еще дня три как минимум с этой установкой прокувыркается). Спрашиваю - на фига вы делали трехзвенку? "Ну так принято...". И что хорошего кроме дополнительной головной боли вы с нее получили? - Чешат репу, молчат. На самых крупных-расперекрупных предприятиях я не видел, чтобы кадровыми вопросами занималось более 10 человек. Спрашивается, на кой нужна трехзвенка?
Короче, в итоге мы от этой системы отказались и ранее уплаченные деньги вернули обратно.
Ну, для ERP, конечно, трехзвенка должна быть выигрышным подходом, если только с умом реализована.

Полностью согласен с Тигрой. Кроме оголтелой веры в новомодное нужен еще и здравый смысел.

Я знаю, что сделать трехзвенную систему ТРУДНЕЕ, сил нужно больше потратить. Иногда это оправдано. Когда есть, ради чего. А когда нет?
Когда прога просто не работает, запустил ее в отладчике и разобрался. А когда у клиента система безопасности отличается от системы безопасности, применяемой у разработчика, то именно при трехзвенной архитектуре возникает вероятность напороться на проблемы. Среднее звено лезет в реестр, а система безопасности его не пущает. Ну ладно, такие-сякие, какого хрена что-то писать в реестр в процессе работы, допустим просто программисты ступили и не сообразили, что не каждый юзер - сисадмин. Но настройка прав доступа производится два раза. Один раз на уровне COM+, другой раз - на уровне СУБД (MS SQL Server). Причем, одна настройка ни в коем случае не должно быть рассогласований в системе безопасности между этими двумя настройками. Программно отследить рассогласования невозможно (нужно опять юзверей в сисадминов превращать). А вручную - очень прикольное занятие (кто тут говорил, что трехзвенку проще настраивать?). Далее - диагностика ошибок. Когда сообщения об ошибках выводятся в диалоговом режиме на экран, то юзер сразу видит, что произошла ошибка, видит какая именно, может позвонить разработчику и крикнуть "караул". А промежуточный уровень - он же на сервере. У него нет никакого визуального интерфейса! Он даже по-человечески сообщить юзеру об ошибке не может. Он просто классически сует сообщения об ошибках в системный журнал приложений (виндовый). Если же ошибка возникает в цикле, то журнал приложений очень быстро разрастается до космических размеров, а комп подвисает, когда дисковое пространство на нем исчерпается. Это называется "защита от глюков с помощью трехзвенки" :)...
Ни о какой простоте настройки и речи не идет. Опять же простая арифметика - настроить две проги проще, чем три. Настроить одно взаимодействие (между клиентом и сервером) проще, чем два взаимодействия (между клиентом и COM+приложением и между COM+приложением и СУБД).
Насчет скорости обмена. Уж не хочешь ли ты сказать, что если поезд от станции А до станции Б идет со скоростью 70км/ч, то добавив между ними станцию В с промежуточной в ней остановкой, можно будет доехать быстрее?
И это далеко не весь перечень проблем, с которыми приходится сталкиваться в подобной трехзвенной архитектуре (конкретно с COM+ их гораздо-гораздо больше). Это так, как говорится, беглый осмотр...

(Вадим)Трехзвенка оправдывает себя экономией на поддержке и сопровождении.

Трехзвенка трехзвенке - рознь. Если в качестве промежуточного звена задействуется COM+приложение, то никакой экономии на поддержке и сопровождении нет. Совсем наоборот, дополнительные расходы времени, сил и денежных средств. Другое дело, если промежуточный уровень сделан с использованием WEB-технологий, и поставщик системы имеет удаленный доступ к настраиваемому объекту - тогда да. Только кто же пустит постороннюю организацию настраивать удаленно свои денежные штучки? Тут нужно преодолеть некоторую грань доверчивости...

По поводу кадров в составе ERP-системы согласен. Если Кадры не самостоятельная система, а часть ERP-системы, тесно с нею увязаная, то трехзвенка может быть вполне оправдана. Я не хочу быть понятым превратно. Я не противник трехзвенки. Я сторонник рационального подхода, когда взвешиваются реальные плюсы и минусы различных технологических концепций, а уже потом принимается решение, а не просто выбирается модная концепция и реализуется в той области, где она дает больше минусов, чем плюсов. Головой думать завсегда полезно.

Может быть, имеет смысл попросить Mazzy, задавшего вопрос, пояснить, что он имел в виду под словосочетанием "хранимые процедуры"? Где именно "хранимые"?