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

Question

Какие преимущества предлагает SQLServer CLR по сравнению с T-SQL? Использование синтаксиса .NET проще, чем T-SQL? Я вижу, что вы можете определять типы пользователей, но я не совсем понимаю, почему это лучше. Например, вы можете определить тип электронной почты, и он будет иметь свойство префикса и свойство домена. Затем вы можете искать по домену или префиксу или обоим. Однако я не понимаю, чем это отличается от добавления пары столбцов, одного из которых называется префикс, а другого - домен, и поиска по ним по отдельности. Может быть, у кого-то есть реальные причины, почему это лучше.

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

Марк

Answer 4

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) и т. д.