ПЕРЕД или ПОСЛЕ триггера для ведения журнала аудита

Question

Я читал поток комментариев MySql 5.0 на странице создания триггера и я хотел бы спросить сообщество, являются ли рекомендации хорошими и относятся ли они к 5.1. Сегодня я заметил, что, играя с триггерами, невозможно обновить поле в старой таблице с помощью ПОСЛЕ ОБНОВЛЕНИЯ.

1. Будьте осторожны с ПЕРЕД триггерами. Могут возникнуть ограничения, особенно если вы используете движок InnoDB, когда вставка завершится неудачно, но действия из вашего триггера BEFORE будут успешными.
2. Используйте триггеры BEFORE в первую очередь для ограничений или правил, а не транзакций, для настройки столбцов NEW. * Все должно быть в порядке.
3. Придерживайтесь триггеров AFTER для большинства других операций, таких как вставка в таблицу истории или обновление денормализации.

Answer 1

Да. AFAIK, MySQL 5.1 не внес никаких изменений в семантику работы триггеров. MySQL пытается поддерживать спецификацию ANSI / ISO SQL для семантики триггера.

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

1. Запуск ДО триггеров
2. Оценивать ограничения, применять NOT NULL, применять DEFAULT значения
3. Запись строки в базу данных
4. Обновление индексов
5. Запуск ПОСЛЕ триггеров

Как только вы достигли триггера AFTER, уже слишком поздно менять значения в строке. В некоторых базах данных вы можете установить NEW.somecolumn = 1234, но это изменение игнорируется по завершении триггера AFTER. В других базах данных он помогает вам понять свою ошибку, сообщая об ошибке либо при определении триггера, либо при запуске триггера.

Триггеры AFTER лучше всего использовать для дополнительных действий, выполняемых в результате INSERT / UPDATE строки, таких как упомянутое вами протоколирование аудита. С одной стороны, MySQL разрешает только один триггер на действие для каждой таблицы, поэтому, если вы также используете триггер BEFORE для изменения значений и применения бизнес-правил, теперь вы можете по крайней мере сохранить дополнительные действия в отдельном триггере. Это облегчает обновление одного или другого.

Другое соображение заключается в том, что вам, вероятно, следует выполнять только дополнительные действия после , когда вы знаете, что строка успешно сохранена. Например. было бы неправильно регистрировать изменения в триггере BEFORE, а затем отменять их из-за ограничения NOT NULL.

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