ДО или ПОСЛЕ запуска для ведения журнала аудита

Question

Я читал поток комментариев MySQL 5.0 на создать триггерную страницу и я хотел бы спросить сообщество, хороши ли рекомендации и применимы ли они по-прежнему к 5.1.Что я заметил, играя с триггерами сегодня, так это то, что невозможно обновить поле в старой таблице, используя AFTER UPDATE.

1. Будьте осторожны с триггерами BEFORE.Могут возникнуть ограничения, особенно если вы используете движок InnoDB, где вставка завершится неудачей, но действия из вашего триггера BEFORE будут успешными.
2. Используйте триггеры BEFORE в первую очередь для ограничений или правил, а не для транзакций, настраивая НОВЫЕ. * столбцы должны быть в порядке.
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 лучше всего использовать для дополнительных действий, которые необходимо выполнить в результате ВСТАВКИ / ОБНОВЛЕНИЯ строки, таких как ведение журнала аудита, о котором вы упомянули.Во-первых, MySQL разрешает только один триггер для каждого действия в таблице, поэтому, если вы также используете триггер BEFORE для изменения значений и применения бизнес-правил, теперь вы можете, по крайней мере, сохранить дополнительные действия в отдельном триггере.Это облегчает обновление того или иного варианта.

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

Для действий по УДАЛЕНИЮ, когда вам нужно удалить зависимые строки в других таблицах, вам все равно может потребоваться сделать это в триггере BEFORE.