Триггер SQLCLR против службы Windows. Когда целесообразно использовать SQLCLR?

Question

У нас есть приложение электронной коммерции .NET с серверной частью SQL Server 2005. Новый заказ требует определенной «постобработки». Эти задачи включают отправку электронной почты, создание файлов, загрузку файлов на FTP-сервер и выполнение операций CRUD для службы данных WCF. Код для выполнения всех этих задач уже существует в виде нескольких библиотек классов .NET.

В моей команде спор о том, где разместить этот код. Я написал простой сервис Windows, который регулярно опрашивает базу данных и, обнаруживая новые транзакции (на основе флагов) в базе данных, выполняет необходимые действия и регистрирует любые ошибки. Альтернативой, которая была предложена, является триггер SQLCLR INSERT, который запускает обработку.

Я знаю, что технически возможно выполнить многие (все?) Из вышеуказанных задач в SQLCLR - я даже нашел несколько статей, объясняющих, как использовать веб-сервисы из SQLCLR, так что, очевидно, люди делают это. Но я все еще колеблюсь. Был ли SQLCLR когда-либо предназначен для такого рода вещей? А если нет, что может быть практическим недостатком? Что касается потенциальных преимуществ триггера SQLCLR над службой Windows, я вижу только одно: меньше трафика в дБ. Первоначально мы ожидаем очень небольшой объем транзакций, поэтому служба Windows будет генерировать «расточительный» трафик. Но служба находится в том же окне, что и база данных, поэтому она даже не влияет на сеть, а только на внутренние ресурсы сервера.

Наконец, третья возможность - использовать триггер SQLCLR для сохранения простого токена в файловой системе и использовать FileSystemWatcher в службе Windows (вместо таймера) для выполнения задач по мере необходимости.

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

Answer 1

Рассматривая аналогичный процесс, мы рассмотрели некоторые вещи.

1. Что происходит, когда зависимая система (mail, ftp) недоступна?
2. Как работает восстановление после сбоя?
3. Если мы находимся в состоянии сбоя, что происходит с новыми записями. Они пытаются сделать пост-процесс, даже когда мы знаем, что система не работает?
4. Каковы навыки тех, кто поддерживает производственную систему?
5. Как контролируется этот процесс?
6. Использует ли система постобработки ресурсы основной системы при обработке? Как бы вы их разделили?
7. Поддерживается ли отработка отказа?

Мы решили использовать Службу Windows, потому что она предоставляла наилучшие возможности тем, кто будет поддерживать систему (людям, которые будут тратить больше времени на сбой сервера, а не на перепуск стека). Так как у него был установлен способ остановки и запуска службы, мониторинг, поддержка кластера, простая разбивка обработки на несколько машин, интеграция с ведением журнала событий и т. Д.

Answer 2

Есть некоторые вещи, для которых SQL CLR был разработан - и это не одна из них, включение такого рода вещей в триггер INSERT действительно заставит младенца Иисуса плакать.

Одним из возможных решений было бы использование Query Notification для облегчения нагрузки между службой и базой данных - можно было бы пойти другим путем, пропустив службу через UDP или что-то подобное.- это означает, что вы не вызываете массовое возникновение на INSERTS (и поэтому не блокируете базовую таблицу на чрезмерное количество времени).