MasterZivНет. Вообще триггера появились в СУБД для реализации ссылочной целостности и реализации примитивной бизнес-логики.
Хотя я бы сказал, что для реализации последнего они в принципе не подходят.
С появлением хранимых процедур и декларативной ссылочной целостности триггера должны сдохнуть как класс.
Ну уж нет. С чего им спрашивается дохнуть ? Ну ка проконтролируйте в бизнес-логике через ХП запрет на удаление задними числами "CreateDate < @@CalcDate", где клиентское приложение делает "DELETE FROM Table WHERE ...". Или Вы считаете, что оно должно открывать курсорчик и по записи лопатить и удалять ? В плане контролирования бизнес-логики в операциях с множествами триггера самое удобное для этого места (особенно если в СУБД есть поддержка BEFORE/AFTER FOR ROW/STATEMENT).

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

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