Это не одно и то же, но они не связаны.
В обоих случаях механизм можно описать примерно следующим образом:
- Какой-то блок кода декларирует «интерес» к изменениям в состоянии.
- Ваше приложение влияет на некоторые изменения.
- Система запускает блок кода в ответ на изменение.
Возможно, триггер базы данных больше похож на функцию обратного вызова, которая зарегистрировала интерес к определенному событию.
Вот аналогия: событие - это резиновый мяч, который вы бросаете. Спусковой крючок - это собака, которая гонится за брошенным мячом.
Если имеется в виду другое различие, которое делает его «опасным» (примечание: OP отредактировал этот выбор слов вне вопроса) для сравнения триггеров и событий, вы можете описать, что вы имеете в виду.
Триггеры - это способ вставить
повторяя логику синхронно в
нить исполнения (т.е.
синхронность). События являются средством для
отложить логику на потом (т.е.
реализовать асинхронность).
Хорошо, я понимаю, что вы имеете в виду более четко. Но я думаю, что это в некоторой степени зависит от реализации. Я бы не предположил, что обработчик событий должен отменить свою регистрацию; это зависит от системы, которую вы используете. Например, обработчик сигналов UNIX должен предотвращать перехват нового сигнала, пока он уже обрабатывает его. Но сервлет Java внутри контейнера Tomcat должен быть потокобезопасным, поскольку он может вызываться одновременно несколькими потоками. Оба они являются обработчиками событий разных типов.
Обработчики событий могут быть синхронными или асинхронными. Может ли обработчик в системе публикации / подписки читать сообщения, которые были опубликованы недавно, но до того, как обработчик зарегистрирует свой интерес? Или только сообщения, отправленные одновременно?
Есть еще одна важная причина трактовать триггеры как отличные от обработчиков событий: я часто рекомендую против делать что-либо в триггере, которое влияет на состояние вне базы данных.
Например, отправка электронной почты, запись в файл, публикация в веб-сервисе или разветвление процесса недопустимы внутри триггера. Если по какой-либо другой причине, кроме транзакции, которая породила триггер, может быть выполнен откат, но вы не можете откатить эти внешние эффекты. Возможно, вы даже не используете явные транзакции, но, скажем, отправляете электронное письмо в триггере BEFORE, но операция завершается неудачей из-за ограничения NOT NULL или чего-то еще.
Вместо этого вся такая работа должна выполняться с помощью кода в приложении, после каждый подтверждает, что операция SQL была успешной и транзакция совершена.
Очень плохо, что люди продолжают пытаться выполнять неуместную работу внутри триггера. В MySQL есть старшие разработчики, которые продвигают UDF для чтения и записи данных в memcached. Вау - я только что заметил, что превратили его в продукт MySQL 6.0 !! Возмутительно!
Итак, вот еще одна попытка провести аналогию, сравнивая триггеры и события с процессом уголовного процесса:
- ПЕРЕД триггером является утверждение.
- Триггер AFTER является обвинительным актом.
- COMMIT - осуждение после обвинительного приговора.
- ROLLBACK - оправдательный приговор по невиновному приговору.
Вы хотите посадить преступника в тюрьму только после того, как он будет осужден.
- Тогда как СОБЫТИЕ - это само преступление.