Столкновение триггеров - мутирующий стол

Question

У меня проблема с таблицей мутаций в Oracle. У меня есть две таблицы, Customer и Person. Я должен обновить ChangeDate в Customer во время изменения строки Person, поэтому я создал триггер. К сожалению, на Customer есть триггер, который в некоторых случаях обновляет Person и вызывает проблему с таблицей мутаций. К счастью, мне не нужно обновлять Customer.ChangeDate при обновлении Person, если это изменение было вызвано изменением Customer.

Итак, вот мой вопрос: как я могу узнать, что триггер Person был запущен триггером Customer?

Answer 1

Ошибки таблицы мутаций почти всегда указывают на проблему с моделью данных или связанными бизнес-процессами. Наиболее распространенной причиной является денормализация, когда данные в одной таблице дублируются каким-либо образом в другой таблице. Похоже, что так и есть - ваша таблица CUSTOMER содержит метаданные о другой таблице, PERSON. Только это усугубляется каскадом информации в другом направлении.

Правильный способ разрешить эту ситуацию - отсортировать модель данных. Является ли CUSTOMER подтипом PERSON или наоборот? Определите, кто является родительским, а какой дочерним, и убедитесь, что информация передается только в одном направлении: возможно, от супертипа к подтипу. Хотя лучшим решением было бы полностью удалить распространение данных.

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

Answer 2

Наконец я использовал global temporary table с очисткой после коммита:

CREATE GLOBAL TEMPORARY TABLE my_temp_table (
  column1  NUMBER,
  column2  NUMBER
) ON COMMIT DELETE ROWS;

Answer 3

@ APC полностью корректен.

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

Вы также можете поместить условия WHEN в условие выполнения триггера.

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