www.fun4me.narod.ruКлиентское приложение не должно полагать, что оно имеет право выдумывать свои собственные операции по работе с данными. Если требуется удалить строки с какими-то опциями, то почему бы не написать процедуру сп_Удалить_Кучу_Записей, с параметрами? В процедуре проверка. И вуаля! Всё просто, быстро и понятно. И переносимо, если процедуры через ODBC {call ...} вызываются.
Клиентское приложение, а так же администратор и проектировщик БД, вправе полагать, что SQL был придуман не только для его использования в хранимых процедурах. Поэтому как клиент, так и клиентское приложение имеют полное право (если конечно есть нужный грант) выполнить DELETE FROM и не "изобретать" процедуру "с кучей параметров" и "геммора". А сама БД вправе полагать, что любое изменение данных, вне зависимости откуда оно будет произведено - с процедуры, ISQL или с менеджера БД и кем - юзером, админом или овнером, будет всегда контролироваться логикой и любое изменение информации приведет к проверке условий, пересчету аггрегатных таблиц и прочих действий. Кроме триггеров больше никто этого гарантировать не может. Так что перед законом все должны быть равны. Хотя тут уже в силу вступает реализация триггеров в каждой СУБД - если она где то урезана функционально, то может действительно оказаться выгоднее все проводить через ХП. У меня, например, в ASA триггера сделаны очень толково - те же BEFORE триггера срабатывают до проверки CHECK и CONSTRAINTS и на момент блокирования записи до начала логирования операции над таблицей. Соотвествующе это дает прекрасную возможность инициализировать значения полей собственными значениями (например если в поле NULL, то занести в него свое значение, или же принудительно привести текстовое поле к верхнему регистру и т.д.). Плюс это позволяет в случае генерации ошибки из триггера быстро откатить операцию, раз не было физической записи в БД и логе и снизить время и ресурсы блокировки обрабатываемых записей (например, если уже на первой записи из обрабатываемого миллиона записей не прошло условие и триггер дал откат, то на текущий момент только первая запись и была блокирована писателем, следующие уже записи блокироваться не будут, операция будет просто прервана). Могу ошибиться, но по моему в Оракле используется такая же эффективная схема работы триггеров (единственное, что там не хватает - это AFTER триггеров на весь массив записей с доступом к нему из триггера, ко временной таблице). Так что в таких случаях по моему грех отказываться от триггеров.

MasterZivВ итоге мораль - триггера будут скоро просто не нужны, а уж о их вреде (для производительности, в основном) давно известно (правда оговорюсь - это зависит от СУБД).
Я бы сказал, что производительность и эффективность триггеров наверное даже больше не от СУБД зависит, а от драйвера "ПрямыеРуки.sys" :)

С ума сойти. Может быть уже и SQL устаревшая технология ? Какие революционные заявления однако :)

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

И где тут наглядное преимущество 3-его звена ? Судя по высказыванию:
автора тем что работаешь не с таблицами БД, а с объектами языка программирования и не ломаешь голову о том как и какие запросы нужно делать, все это делает какая-нить служба persistent manager сервера приложений.
самое лучшее преимущество - это то, что не нужно учить правила проектирования БД и SQL (и возможно кое где менять взгляды на жизнь), а делать приложения на привычных классах и получать большую зп только из за того, что сама трудоемкость создания 3-х звенных приложений (особенно на J2EE) повыше будет, чем у 2-х звенок :)