ДО или ПОСЛЕ триггера для ведения журнала аудита
Я читал поток комментариев MySql 5.0 на создать страницу триггера и я хотел бы спросить сообщество, верны ли рекомендации и применимы ли они к 5.1. Сегодня я заметил, играя с триггерами, что невозможно обновить поле в старой таблице с помощью ПОСЛЕ ОБНОВЛЕНИЯ.
- Будьте осторожны с триггерами ДО. Могут возникнуть ограничения, особенно если вы используете движок InnoDB, когда вставка завершится ошибкой, но действия из вашего триггера BEFORE будут успешными.
- Используйте триггеры BEFORE в первую очередь для ограничений или правил, а не для транзакций, настройка столбцов NEW. * Подойдет.
- Используйте триггеры AFTER для большинства других операций, таких как вставка в таблицу истории или обновление денормализации.
Ответы 1
Да. AFAIK, MySQL 5.1 не внес никаких изменений в семантику работы триггеров. MySQL пытается поддерживать спецификацию ANSI / ISO SQL для семантики триггеров.
Вы можете представить себе последовательность операций, выполняемых по мере записи строки в базу данных:
- Запускать ДО триггеров
- Оценить ограничения, применить
NOT NULL, применить значенияDEFAULT - Записываем строку в базу данных
- Обновить индексы
- Запускать ПОСЛЕ триггеров
Как только вы дойдете до триггера AFTER, уже слишком поздно изменять значения в строке. В некоторых базах данных вы можете установить NEW.somecolumn = 1234, но это изменение автоматически отменяется по завершении триггера AFTER. В других базах данных он помогает понять свою ошибку, выдавая ошибку либо при определении триггера, либо при запуске триггера.
Триггеры AFTER лучше всего использовать для дополнительных действий, которые необходимо предпринять в результате INSERT / UPDATE строки, например, упомянутого вами журнала аудита. Во-первых, MySQL разрешает только один триггер для каждого действия для каждой таблицы, поэтому, если вы также используете триггер BEFORE для изменения значений и обеспечения соблюдения бизнес-правил, теперь вы можете по крайней мере сохранить дополнительные действия в отдельном триггере. Это упрощает обновление одного или другого.
Другое соображение заключается в том, что вам, вероятно, следует выполнять дополнительные действия только с после, если вы знаете, что строка была успешно сохранена. Например. было бы неправильно регистрировать изменение в триггере BEFORE, а затем отменять изменение из-за ограничения NOT NULL.
Для действий DELETE, где вам нужно удалить зависимые строки в других таблицах, вам все равно может потребоваться сделать это в триггере BEFORE.
Спасибо за развернутый ответ. Я решил обновить столбец dateChanged вручную, а не полагаться на триггер.