избавиться от триггера вставки

Question

Попытка найти решения, альтернативные использованию триггеров вставки.Как на основе API и плюсы и минусы с различными подходами.

Answer 1

В подходе API вы должны создать процедуру для выполнения обеих операций - что-то вроде:

package body emp_api is

    procedure insert_emp (...) is
    begin
        insert into emp (...) values (...);
        -- Insert that was previously in trigger
        insert into other_table (...) values (...);
    end;
end;

Затем вы заставляете приложений использовать API, предоставляя им EXECUTE доступ кПакет API, но нет доступа INSERT / UPDATE / DELETE к таблицам.

Answer 2

В DDL. Вы можете отключить триггер с помощью ALTER TRIGGER или ALTER TABLE.

ALTER TRIGGER triggername DISABLE;  -- disable a single trigger

ALTER TABLE tablename DISABLE ALL TRIGGERS; -- disable all triggers on a table

Чтобы сделать это во время выполнения, вам придется использовать динамический SQL, и схема, в которой выполняется процедура, должна иметь собственныйтаблица или иным образом имеют необходимые привилегии.

EXECUTE IMMEDIATE 'ALTER TRIGGER tablename DISABLE ALL TRIGGERS';

Для получения дополнительной информации о включении / отключении триггеров см. http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/general004.htm

Answer 3

Если вы хотите гарантировать, что у вас будет запись, вставленная в таблицу B, когда что-то вставится в таблицу A, сохраните триггер. Вы можете отключить массовую загрузку в tableA и гарантировать, что у вас будет единственная загрузка процесса в эту таблицу в течение этого времени.

Как только вы удаляете триггер, у вас НЕТ гарантий относительно вставок в таблицу B. Ваша единственная надежда состоит в том, что все без исключения программы, которые могут быть вставлены в таблицу A (вы действительно знаете все это?), Придерживаются вторичной вставки в таблицу B. Это «целостность данных с помощью политики компании», а не целостность данных, реализуемая с помощью Oracle.

Этот подход зависит от того, насколько вы заботитесь о состоянии данных в таблице B, я полагаю.

Я бы НЕ пошел по пути таблицы apis (TAPI), которая теперь форсирует любые / все операции через некоторые pl / sql api, которые обрабатывают логику. Они почти всегда имеют тенденцию быть медленными и ошибочными в моем опыте.