Может SQL триггеры CLR делать это? Или есть ли лучший путь?

То, что Вы описываете, иногда называют Очередью заданий или Очередью сообщений. Существует несколько потоков об использовании таблицы DBMS (а также другие методы) для того, чтобы сделать это, что можно найти путем поиска.

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

Я предложил бы иметь триггер на таблице, которая звонит Брокеру SQL Server Service, который затем (асинхронно) выполняет хранимую процедуру CLR, которая делает всю Вашу работу в другом потоке.

Почему бы не реализовать вставку в хранимой процедуре и сделать бизнес-логику в процедуре после вставки? Что является так сложным об этом, что это не может быть записано в T-SQL?

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

Я не рекомендовал бы использовать триггер CLR или любой вид триггера для этого. Вы открываете себя для наличия серьезной пригодности для обслуживания и потенциальных проблем блокировки. (Очень простой триггер, который зажимает материал в таблицу аудита/очереди, может быть приемлемым, ЕСЛИ Вы не заботитесь о @@, идентификационные данные после вставляют, и Вы никогда не будете запирать таблицу аудита/очереди),

Вместо этого от Вашего application/orm необходимо инициировать вставку материала в таблицу очереди и обрабатывать эту очередь регулярно. Это может быть сделано при наличии транзакции в Вашем ORM или начинания сохраненный proc запуски, транзакция фиксирует изменение и аудит/очередь атомарно. (будьте осторожны с блокировкой здесь),

Если Вам нужно незамедлительное принятие мер, взгляд на порождение задания для очистки очереди после того, как Вы сделаете вставление/обновление/удаление на таблице и

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