Преимущество SQL SERVER CLR

Разные цели. Хранимая процедура CLR полезна в тех случаях, когда написание высоко процедурного кода или использование системных средств, недоступных из T-SQL, было бы полезным. Хотя нет никаких причин, по которым нельзя писать sproc приложения против него, обычно вы не рассматриваете sproc CLR как просто другой язык для написания sproc приложения. Как правило, sproc среды CLR чаще всего используется для системных целей, а не для компонентов приложения, хотя это ни в коем случае не является жестким правилом.

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

T-SQL выполняет традиционные функции базы данных и интегрируется с оптимизатором запросов, поэтому он по-прежнему наиболее подходит для кода базы данных, ориентированного на наборы. Существуют перехватчики API для sprocs CLR, которые предоставляют информацию оптимизатору запросов, но это добавляет сложности.

Можно также использовать интеграцию CLR для определения функций, доступных для кода T-SQL. В некоторых случаях они могут быть быстрее и эффективнее с точки зрения памяти, чем функции T-SQL. Пресс-книга Wrox по интеграции с CLR обсуждает это довольно подробно.

Я приведу один хороший пример: в CLR есть встроенный объект RegEx, которого очень не хватает в SQL Server. Теперь тривиально написать функции для выполнения ограничений / исправлений проверки на основе регулярных выражений.

Вы также можете, например, вызвать внешний веб-сервис из метода SQLCLR - это не совсем возможно в T-SQL :-)

Марк

Интеграция SQLCLR / CLR в SQL Server - это просто еще один инструмент, помогающий решить некоторые (не все) проблемы. Есть несколько вещей, которые он делает лучше, чем то, что можно сделать в чистом T-SQL, а есть некоторые вещи, которые можно сделать только через SQLCLR. Я написал статью для SQL Server Central, Лестница на уровень SQLCLR 1. Что такое SQLCLR? (для чтения статей там требуется бесплатная регистрация), в которой рассматривается этот вопрос. Основы (подробности см. В связанной статье):

• Потоковые функции с табличными значениями (sTVF)
• Динамический SQL (внутри функций)
• Лучший доступ к внешним ресурсам / замена xp_cmdshell
  • Передавать данные проще
  • Получить несколько столбцов набора результатов проще
  • Нет внешних зависимостей (например, 7zip.exe)
  • Лучшая безопасность за счет имитации
• Возможность многопоточности
• Обработка ошибок (в функциях)
• Пользовательские агрегаты
• Пользовательские типы
• Изменить состояние (внутри функции и без OPENQUERY / OPENROWSET)
• Выполнение хранимой процедуры (только для чтения; в функции и без OPENQUERY / OPENROWSET)
• Производительность (Примечание: это нет означает во всех случаях, но определенно в некоторых случаях в зависимости от типа и сложности операции)
• Может захватывать вывод (то есть то, что отправляется на вкладку сообщений в SSMS) (например, PRINT и RAISERROR с строгость = от 0 до 10) - я забыл упомянуть об этом в статье ;-).

Еще одна вещь, которую следует учитывать, заключается в том, что иногда полезно иметь возможность совместно использовать код между приложением и БД, чтобы БД имела представление об определенной бизнес-логике без необходимости создавать настраиваемые экраны, предназначенные только для внутреннего использования, только для доступа к этому коду приложения. Например, я работал над системой, которая импортировала файлы данных от клиентов и использовала собственный хеш для большинства полей и сохраняла это значение в строке в базе данных. Это позволяло легко пропускать строки при повторном импорте их данных, поскольку приложение будет хешировать значения из входного файла и сравнивать их с хеш-значением, хранящимся в строке. Если бы они были такими же, тогда мы сразу узнали, что ни одно из полей не изменилось, поэтому мы перешли к следующей строке, и это было простое сравнение INT. Но этот алгоритм для выполнения хеширования был только в коде приложения, поэтому будь то для отладки случая клиента или поиска способов передать некоторую обработку серверным службам, пометив строки, в которых было хотя бы одно поле, с изменениями (изменения, поступающие из нашего приложения вместо того, чтобы искать изменения в новом файле импорта), я ничего не мог сделать. Это было бы прекрасной возможностью иметь довольно простую часть бизнес-логики в БД, даже если бы не для нормальной обработки; наличие того, что составляет закодированное значение в БД, без возможности понять его значение, значительно затрудняет решение проблем.

Если вам интересно увидеть некоторые из этих возможностей в действии без необходимости писать какой-либо код, бесплатная версия SQL # (автором которой я являюсь) имеет функции RegEx, настраиваемые агрегаты (UDA), настраиваемые типы (UDT) и т. д.