Мне нужна аналогия: триггеры и события

Что касается другого вопроса, я сталкиваюсь с заблуждением, которое, кажется, иногда возникает здесь, в SO. Некоторые спрашивающие, кажется, думают, что триггеры для баз данных так же, как события для ООП.

Есть ли у кого-нибудь хорошая аналогия, чтобы объяснить, почему это ошибочное сравнение, и последствия его неправильного применения?

РЕДАКТИРОВАТЬ:

Билл К. понял это правильно, но, возможно, не видит важности критической разницы между событием и функцией обратного вызова, которая меня все равно поражает. Триггеры фактически вызывают выполнение кода каждый раз, когда происходит событие; обратные вызовы происходят только тогда, когда кто-то был зарегистрирован для участия в событии (что неверно для подавляющего большинства событий); и даже в этом случае в большинстве случаев первым действием обратного вызова является отмена регистрации (или, по крайней мере, обратный вызов содержит квалификационный выход, поэтому он выполняется только один раз).

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

Триггеры — это способ синхронно вставить повторяющуюся логику в поток выполнения (т. е. синхронность). События — это средство отложить логику на потом (т. е. реализовать асинхронность).

В обоих случаях есть исключения и смягчения, но основные шаблоны триггеров и обратных вызовов в основном противоположны по замыслу и реализации. Часто кажется, что различие не полностью осознано (ИМХО, YMMV). :D


events triggers
person dkretz    schedule 30.01.2009    source источник

Ответы (1)


arrow_upward
8
arrow_downward

Это не одно и то же, но они не связаны.

В обоих случаях механизм можно описать примерно так:

  • Некоторый блок кода объявляет «интерес» к изменениям состояния.
  • Ваше приложение влияет на некоторые изменения.
  • Система запускает блок кода в ответ на изменение.

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

Вот аналогия: событие — это резиновый мячик, который вы бросаете. Триггер — это собака, которая гонится за брошенным мячом.

Если вы имеете в виду какое-то другое различие, которое делает его «опасным» (примечание: OP отредактировал этот выбор слова, исключенный из вопроса) для сравнения триггеров и событий, вы можете описать, что вы имеете в виду.

Триггеры — это способ синхронно вставить повторяющуюся логику в поток выполнения (т. е. синхронность). События — это средство отложить логику на потом (т. е. реализовать асинхронность).

Хорошо, я понимаю, что вы имеете в виду, более ясно. Но я думаю, что это в некотором роде зависит от реализации. Я бы не стал предполагать, что обработчик событий должен отменить регистрацию; это зависит от системы, которую вы используете. Обработчик сигнала UNIX, например, должен предотвратить перехват нового сигнала, пока он уже обрабатывает его. Но сервлет Java внутри контейнера Tomcat должен быть потокобезопасным, поскольку он может вызываться одновременно несколькими потоками. Оба они являются обработчиками событий разных типов.

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

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

Например, отправка электронной почты, запись в файл, отправка в веб-службу или разветвление процесса внутри триггера неуместны. Если ни по какой другой причине, кроме транзакции, породившей триггер, можно откатить, но вы не можете откатить эти внешние эффекты. Возможно, вы даже не используете явные транзакции, но говорите, что отправляете электронное письмо в триггере BEFORE, но операция не выполняется из-за ограничения NOT NULL или чего-то еще.

Вместо этого вся такая работа должна выполняться кодом в приложении, после подтверждения того, что операция SQL прошла успешно и транзакция зафиксирована.

Очень плохо, что люди продолжают пытаться выполнять неподходящую работу внутри триггера. В MySQL есть старшие разработчики, которые продвигают UDF для чтения и записи данных в memcached. Вау! Я только что заметил, что они сделали это в продукт MySQL 6.0!! Шокирует!

Итак, вот еще одна попытка провести аналогию, сравнивая триггеры и события с процессом уголовного процесса:

  • Триггер BEFORE — это утверждение.
  • Триггер ПОСЛЕ — это обвинительный акт.
  • COMMIT — осуждение после вынесения обвинительного приговора.
  • ROLLBACK - это оправдательный приговор после невиновного приговора.

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

  • Тогда как СОБЫТИЕ - это само преступление.
person Bill Karwin    schedule 30.01.2009
comment
Я полагаю, что «он» имеет в виду определенное более скрытное отношение к тому, какая фундаментальность имеет смысл в триггере. - person Mitch Wheat; 30.01.2009
comment
так что тупик - это когда 2 собаки хватаются за один и тот же мяч? ;) - person Mitch Wheat; 30.01.2009
comment
Одним из конкретных примеров был вызов веб-службы с помощью CLR из триггера. Я называю это опасным. - person dkretz; 30.01.2009
comment
Похоже, MySQL подхватил хроническую болезнь Солнца — Microsoft Envy. Попытка сопоставить функцию с функцией. - person dkretz; 30.01.2009