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

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

Ответы

Ответ 1

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

Ответ 2

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

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

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

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

Ответ 3

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

Марк

Ответ 4

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