Как стать автором
Обновить

Комментарии 6

Фича конечно интересная, но неужели кто-то ей реально пользуется? Вместо того, чтобы разгребать этот trigger hell, не проще ли сделать пакет, какой-нибудь dml_orders, который будет единственным разрешенным интерфейсом для обновления данных в таблицах? Если планируются mass updates, то лучше предусмотреть отдельную функцию с каким нибудь ref cursor на входе, чем городить лапшу из триггеров.

Некоторые внешние сервисы, например symmetricds (для синхронизации данных между базами) взаимодействуют с таблицами напрямую. По этой причине проще реализовать составной триггер, который будет лежать в vcs рядом с таблицей(что достаточно наглядно), чем усложнять процесс вспомогательными процедурами и пакетами и, тем более, функциями с refcursor. Да, с нагрузкой триггеры не дружат, но не везде есть нагрузка.

Не нравятся нативные решения sql - никто не запрещает реализовать это отдельным сервисом, а базу использовать как хранилище.

Архитектор is null.

Будь не так - не пустили бы внешние сервисы куролесить в БД.

Поделитесь своим архитектурным опытом, думаю многим будет интересно. CDC за вечер напишите сами, который будет надёжнее существующих решений и не будет напрямую ходить в базу, а через какие-то обертки/хранимки?

Первое правило использования триггеров - не используйте триггеры

Упоминание ORA-04091 навело на мысль, что теперь есть какое-то интересное решение для её обхода. А оказалось, это просто синтаксический сахар для объединения 4 типов уже существующих триггеров в типа один.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории