MasterZiv
Триггера появились в СУБД ДО появления поддержки декларативной ссылочной целостности.

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

MasterZiv
Можно вместо DML вызывать процедуру.

Что угодно, только не это. БД вообще предназначена для многих программ и их авторы не обязаны знать о каких-то там процедурах вместо DML. Но используя DML они не должны нарушить целостность БД, а так же операций, которые проектировщик БД считает обязательными. Например, автоматическое заполнение вычисленимых полей. Знание же DML как DL от них можно требовать. Зачем изобретали язык БД? Разве не для того, чтобы его все использовали? А о триггере им знать ничего не надо - он сам напомнит о себе. Представляете, что проги-клиенты от производителя СУБД ничего не знают об этих процедурах вместо DML, зато нарушить DML они не могут - это СУБД гарантирует и оно же гарантирует срабатывание триггера.


MasterZiv
Тогда никаких событий не нужно. Все то же самое можно сделать и в процедуре.

Не все. Процедуру еще надо вызывать. А, например, закрыть БД можно с помощью прог управления операционной системы, а в общем случае она может закрыться даже в результате сбоя. На это может сработать триггер.

MasterZiv
Процедура имеет нормальную и гибкую логику работы ( в отличие от триггеров, работа которых должна быть согласованной с основной модификацией данных, производится ТОЛЬКО внутри транзакции и т.п.).

Будучи процедурой и имея возможность из своего тела вызывать процедцуры, триггер в гибкости не может сильно проигрывать в плане логики. Согласованность работы с модификацией данных - это возможно достоинство - дополнительная гибкость в плане управления модификацией. А возможность вызова процедуры в ответ на событие тоже способстует повышению гибкости в управлении данными - дополнительный способ вызова процедур. Кроме того, разные проги могут иметь разные процедуры обновления данных и отделение процедур вызываемых на события от процедур вызывающих эти события тоже вносит лепту в гибкость - например, легче все это исправлять при изменении правил, которым должны отвечать данные.

MasterZiv
Процедура позволяет скрывать от приложения структуру базы данных, что добавляет доп. гибкость.

Для этой цели СУБД имеет специальные средства: представления, синонимы, систему прав. Кроме того, опять триггер - особая, но процедура.



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

Не смотря на всю прользу от развития декларативной ссылочной целостности, продолжают развиваться и триггера. Так в Орале 9 появилось концепция приостановленной инструкции. Если в ходе выполнения инструкции возникла проблема доступности пространства, Oracle может перевести ее режим приостановления до тех пор пока эта проблема не будет решена. С данным событием можно связать триггер, автоматически уведомляющий пользователя или приложение о проблеме и даже самомтоятельно ее устраняющий.



savage79
Согласен что для современных систем триггеры и прочая фигня, вполодь до ссылочной целостности зачастую уже и не нужно. Объясню почему. Раньше народ писал клиент-серверный софт и тогда, чтобы им не заморачиваться с отслеживанием на клиенте целостности и непротиворечивости данных в БД использовались триггеры и хр.процедуры. Сейчас софт пишут с использованием 3х- и более звенной архитектуры, где вся бизнес логика сосредоточена на сервере приложений, который и отвечает за работу с данными.

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