Почему мы используем процедуры CLR

Есть несколько вещей, которые не могут быть выполнены в SQL Server (или в некоторых случаях это не выполняется, а также в управляемом коде).

• CLR имеет RegEx.
• Вы можете позвонить в веб-службы.
• CLR имеет лучшую производительность (если вам приходилось делать много математики в каждой строке, например)
• Повторное использование кода
• Напишите на языке, к которому вы привыкли (VB.Net, С# и т.д.).

Я отправил следующий ответ на аналогичный вопрос: Преимущество SQL SERVER CLR. Я добавлю здесь, хотя, учитывая, что что-то упоминалось, по крайней мере, в двух ответах: С#/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) и т.д.

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

Вы также можете записывать агрегированные функции с помощью процедур CLR, которые не могут быть выполнены в T-SQL.

Конечно, для обработки данных хранимые процедуры T-SQL будут работать лучше и легче писать.

Ну, если вы хотите:

• выполнять сложные операции с данными и
• хотите быть близкими к данным (т.е. не в ASP.NET или в приложении Winforms) и
• вы предпочитаете писать код на С#, чем SQL.

Это тот случай, когда вы используете процедуру CLR. У меня нет примера с головы, но его можно представить.

- Изменить:

Представьте, что можно преобразовать данные в структуру типа datawarehouse. В этом случае вы можете переформатировать и провести анализ. Тогда может быть целесообразным сделать это в CLR. (Я не утверждаю, что это именно то, что я сделал бы, но это можно было бы рассмотреть).