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

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

Разные цели. Хранимая процедура 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 обсуждается это в некоторых глубина.

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

Марк

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

• Потоковые функции с табличными значениями (sTVF)
• Динамический SQL (внутри функций)
• Better Access to External Resources / Replace xp_cmdshell
  • Passing data in is easier
  • Получить несколько столбцов набора результатов проще
  • Никаких внешних зависимостей (например, 7zip.exe)
  • Повышенная безопасность за счет выдачи себя за другое лицо
• Возможность многопоточности
• Обработка ошибок (в функциях)
• Пользовательские агрегаты
• Пользовательские типы
• Изменить состояние (внутри функции и без OPENQUERY / OPENROWSET)
• Выполнение хранимой процедуры (только для чтения; внутри функции и без OPENQUERY / OPENROWSET)
• Производительность (примечание: это не означает во всех случаях, но определенно в некоторых случаях в зависимости от типа и сложности операции)
• Может захватывать вывод (т.е. то, что отправляется на вкладку «Сообщения» в SSMS) (например, PRINT и RAISERROR с серьезностью = от 0 до 10) - я забыл упомянуть об этом в статье ;-).

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

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