I.Tal,

Есть простое, очевидное, элегантное, но в большинстве случаев неправильное решение.
Можно сделать по внешним UDF/хранимой процедуре, но это в определённой степени извращение для таких задач. Тонкости вылезают с транзакционностью.
1) Транзакция "триггер" имеет полное право откатиться, а потом повториться (вызовет дубликаты событий). Способ бороться - транзакция-триггер - только вызывает приложение, сканирующее таблицу-очередь уже закоммиченных событий.
2) Обработчик события может не отработать по каким-то там причинам. Событие "пропадёт"

Планировщик же - самое оно. Единичные коннекты раз в N секунд/минут - очень недорогая операция (скорее проверка, превратившаяся в полный скан таблицы, может сожрать больше). Главное - смотрите, чтобы база активна была (activate database ...).

I.Tal,

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

Если очень надо, и это возможно, то заверните логику приложения в хранимую процедуру и вызывайте из триггера по событию. Но только не внешнее приложение.
Я бы сказал, что если очень-очень надо, то триггер (внешняя функция/хранимая процедура, дергаемая триггером) может запускать внешнее приложение, которое обладает определёнными характеристиками:
- приложение (код ф-и/процедуры) отрабатывает очень быстро и не делает НИЧЕГО.
- кромо как или а) посылает синал своей серверной части - "пора!", или б) запускает в параллель дополнительный процесс.

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

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

Схема имеет хоть какой-то смысл если вам действительно надо, чтобы по факту изменений что-то отрабатывало не через 5 секунд, и не через одну, а "вот прям сразу", и к архитектуре приложения, изменяющего базу, вы доступа не имеете.
И то, весьма вероятно, Q-Replication/CDC replication будут гораздо более надёжными средствами.