Комментарии 6
Фича конечно интересная, но неужели кто-то ей реально пользуется? Вместо того, чтобы разгребать этот trigger hell, не проще ли сделать пакет, какой-нибудь dml_orders, который будет единственным разрешенным интерфейсом для обновления данных в таблицах? Если планируются mass updates, то лучше предусмотреть отдельную функцию с каким нибудь ref cursor на входе, чем городить лапшу из триггеров.
Некоторые внешние сервисы, например symmetricds (для синхронизации данных между базами) взаимодействуют с таблицами напрямую. По этой причине проще реализовать составной триггер, который будет лежать в vcs рядом с таблицей(что достаточно наглядно), чем усложнять процесс вспомогательными процедурами и пакетами и, тем более, функциями с refcursor. Да, с нагрузкой триггеры не дружат, но не везде есть нагрузка.
Не нравятся нативные решения sql - никто не запрещает реализовать это отдельным сервисом, а базу использовать как хранилище.
Первое правило использования триггеров - не используйте триггеры
Упоминание ORA-04091 навело на мысль, что теперь есть какое-то интересное решение для её обхода. А оказалось, это просто синтаксический сахар для объединения 4 типов уже существующих триггеров в типа один.
Использование составных триггеров (compound triggers) Oracle