Значительная часть того, что будет определять, как лучше всего уведомлять пользователей, зависит от того, какие типы (-ы) уведомлений (-ов) вы говорите. Тем не менее, я не думаю, что SMO собирается сделать что-нибудь для вас в отношении уведомлений, так как это действительно облегчает общее взаимодействие с метаданными.
Если вы просто хотите отправлять пользователям по электронной почте, вы должны позвонить sp_send_dbmail через триггер T-SQL. Эта системная хранимая процедура выполняется асинхронно через Service Broker, поэтому она не будет (по крайней мере, не должна) удерживать оператор DML.
Если вам нужно позвонить в веб-службу, вы можете использовать с помощью триггера SQLCLR или триггера T-SQL, вызывающего функцию/хранимую процедуру SQLCLR. Недостатком здесь является то, что существует гораздо больший потенциал для того, чтобы оператор DML зависал, пока вызов веб-службы ожидает ответа или даже ждет возможности сделать запрос (в зависимости от того, как настроено максимальное количество подключений).
У вас также есть возможность получить необходимую информацию о запуске триггера T-SQL в таблицу очередей, а затем выполнить задание агента SQL Server каждую минуту или около того для обработки записей в этой таблице очередей. Просто не забудьте удалить записи после их обработки. Этот вариант, естественно, асинхронен, поэтому вызов Web Service через SQLCLR намного менее рискован. Или этот подход может использоваться в сочетании с sp_send_dbmail, так что у вас есть «мгновенное» уведомление по электронной почте плюс возможность сделать что-то более общее с этими данными в таблице очередей, например отправить его в общую базу данных аудита, чтобы пользовательский интерфейс могут быть добавлены, чтобы иметь более «глобальный» взгляд на то, что меняется, что многие люди могут просматривать через ваше приложение.
Где ваши пользователи (например, приложение для Windows, веб-браузер, приложение для телефона, Excel и т. Д.) – adrianm