Я отправил следующий ответ на аналогичный вопрос: Преимущество SQL SERVER CLR .
Я добавлю здесь, однако, что C # / VB.net / etc, являющийся языком, с которым кому-то удобнее, чем T-SQL, должен , а не быть причиной для использования SQLCLR вместо T-SQL. Если кто-то не знает, как что-то сделать в T-SQL, сначала обратитесь за помощью в поиске решения T-SQL. Если он не существует, , тогда идите по маршруту CLR.
SQLCLR / CLR Интеграция в SQL Server - это еще один инструмент, помогающий решить некоторые (не все) проблемы. Есть несколько вещей, которые он делает лучше, чем то, что можно сделать в чистом T-SQL, и есть некоторые вещи, которые можно сделать только через SQLCLR. Я написал статью для SQL Server Central, Stairway to SQLCLR Level 1: Что такое SQLCLR? (для чтения статей там требуется бесплатная регистрация), в которой рассматривается этот вопрос. Основы (см. Связанную статью для деталей):
- Потоковые функции с табличным значением (sTVF)
- Динамический SQL (внутри функций)
- Улучшение доступа к внешним ресурсам / замена xp_cmdshell
- Передача данных проще
- Проще вернуть несколько столбцов из набора результатов
- Нет внешних зависимостей (например, 7zip.exe)
- Лучшая защита через олицетворение
- Возможность многопоточности
- Обработка ошибок (в пределах функций)
- Пользовательские агрегаты
- Пользовательские типы
- Изменить состояние (внутри функции и без
OPENQUERY / OPENROWSET)
- Выполнить хранимую процедуру (только для чтения; внутри функции и без
OPENQUERY / OPENROWSET)
- Производительность ( примечание: это не означает во всех случаях, но определенно в некоторых случаях в зависимости от типа и сложности операции)
- Может захватывать выходные данные (то есть то, что отправляется на вкладку «Сообщения» в SSMS) (например,
PRINT и RAISERROR с серьезностью = от 0 до 10) - я забыл упомянуть об этом в статья; -).
Еще одна вещь, которую следует учитывать, это то, что иногда полезно иметь возможность обмениваться кодом между приложением и БД, чтобы БД понимала определенную бизнес-логику, не создавая собственные экраны только для внутреннего использования, чтобы получить доступ к этому. код приложения. Например, я работал над системой, которая импортировала файлы данных от клиентов и использовала собственный хэш большинства полей и сохранила это значение в строке в БД. Это позволило легко пропустить строки при повторном импорте их данных, поскольку приложение будет хэшировать значения из входного файла и сравнивать с хеш-значением, хранящимся в строке. Если они были одинаковыми, то мы сразу знали, что ни одно из полей не изменилось, поэтому мы перешли к следующему ряду, и это было простое сравнение с INT. Но этот алгоритм для выполнения хеширования был только в коде приложения, так что будь то для отладки клиентского случая или для поиска способов переложить некоторую обработку на внутренние сервисы, помечая строки, в которых было хотя бы одно поле с изменениями (изменения поступили из нашего приложения в отличие от поиска изменений в более новом файле импорта), я ничего не мог сделать. Это было бы отличной возможностью иметь довольно простую часть бизнес-логики в БД, даже если бы не обычная обработка; наличие того, что равнозначно закодированному значению в БД, и неспособность понять его значение значительно затрудняет решение проблем.
Если вы заинтересованы в том, чтобы увидеть некоторые из этих возможностей в действии без необходимости писать какой-либо код, бесплатная версия SQL # (автором которой я являюсь) имеет функции RegEx, пользовательские агрегаты (UDA), пользовательские типы (UDT) и т. д.