Преимущество SQL SERVER CLR
Какие преимущества предлагает SQLServer CLR по сравнению с T-SQL? Использование синтаксиса.NET проще, чем T-SQL? Я вижу, что вы можете определять типы пользователей, но я не совсем понимаю, почему это лучше. Например, вы можете определить тип электронной почты, и он будет иметь свойство префикса и свойство домена. Затем вы можете искать по домену или префиксу или обоим. Однако я не понимаю, чем это отличается от добавления пары столбцов, одного из которых называется префикс, а другого - домен, и поиска по ним по отдельности. Может быть, у кого-то есть реальные причины, почему это лучше.
4 ответа
Я приведу один хороший пример: в CLR есть встроенный объект RegEx, которого очень не хватает в SQL Server. Теперь тривиально писать функции для выполнения проверочных ограничений / исправлений на основе регулярных выражений.
Разные цели. Хранимая процедура CLR полезна для вещей, где было бы полезно написать высокопроцедурный код или использовать системные средства, недоступные из T-SQL. Хотя нет никакой внутренней причины, по которой нельзя писать спроков приложения против него, обычно вы бы не рассматривали спроков CLR как просто другой язык для написания спроков приложений. Как правило, большинство применений sproc CLR будет использоваться для системных целей, а не для компонентов приложения, хотя это никоим образом не является жестким и быстрым правилом.
Уровень интеграции CLR предлагает некоторые средства, которые не доступны напрямую из хранимых процедур T-SQL, например пользовательские агрегатные функции. Он также предлагает доступ к библиотекам.Net, которые могут быть полезны для получения доступа к функциям, которые T-SQL не может поддерживать.
T-SQL выполняет традиционные операции с базами данных и интегрируется с оптимизатором запросов, поэтому он по-прежнему наиболее подходит для ориентированного на множество кода базы данных. Существуют хуки API для sprocs CLR, которые предоставляют информацию оптимизатору запросов, но это добавляет сложности.
Можно также использовать интеграцию CLR для определения функций, доступных для кода T-SQL. В некоторых случаях они могут быть быстрее и эффективнее использовать память, чем функции T-SQL. В пресс-книге Wrox по интеграции CLR это подробно обсуждается.
Например, вы также можете вызвать внешний Web-сервис из метода 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) и т. Д.