каковы возможные проблемы с интеграцией CLR в Sqlserver
Не каждый язык поддерживает отражение, но принципы обычно являются тем же на языках, которые поддерживают его.
Отражение является способностью "отразиться" над структурой Вашей программы. Или более конкретный. Для рассмотрения объектов и классов, Вы имеете и программно возвращаете информацию о методах, полях и интерфейсах, которые они реализуют. Можно также посмотреть на вещи как аннотации.
Это полезно в большом количестве ситуаций. Везде Вы хотите быть в состоянии динамично включить классы в свой код. Партия объектных реляционных картопостроителей использует отражение, чтобы быть в состоянии инстанцировать объектов от баз данных, не зная заранее, что возражает, что они собираются использовать. Сменная архитектура является другим местом, где отражение полезно. Способность динамично загрузить код и определить, существуют ли типы там, которые реализуют правильный интерфейс для использования в качестве плагина, важна в тех ситуациях.
4 ответа
Интеграция CLR в SQL Server сама по себе не является нестабильной. В качестве доказательства я укажу вам на тот факт, что в SQL Server 2008 группа системных типов данных была реализована как типы данных CLR, например новые типы geography и geometry . Таким образом, среда CLR была признана достаточно безопасной, чтобы на ней можно было основывать новые основные функции.
При этом CLR привносит в программирование SQL целый новый арсенал, чтобы выстрелить себе в ногу. Вы можете запускать потоки, блокировать связь IPC (события, мьютексы, семафоры), подключаться извне и ждать ввода-вывода, читать / писать в памяти, вызывать различные Win32 APIS и вообще вести себя опрометчиво и сеять хаос. Старое программирование на T-SQL требовало гораздо большего хакерского таланта для достижения того же.
Вы планируете реализовать новый тип данных, который предоставляет красивый, ограниченный, поведение, например, проверка регулярного выражения поля? Преуспевать. Вы собираетесь делать запросы к веб-службам из среды CLR, размещенной на SQL? Вы получите его, и вы заслужите все, что получите!
Практическое правило: если ваша сборка будет загружаться и проверяться без заслуживающих доверия требований (без EXTERNAL_ACCESS, без UNSAFE), тогда все будет в порядке. Конечно, вы все еще можете писать циклы while (1) {;} в сборках SAFE, но тогда то же самое может быть и для хранимой процедуры T-SQL ...
Одна из проблем заключается в том, как получить ассистент CLR (производственный) на сервере. Например, у нашей компании есть клиенты, которые предоставляют нам доступ не к своим SQL-серверам, а как удаленное соединение через SSMS. Таким образом, нет локального пути, по которому вы можете развернуть свою сборную dll. Решение состоит в том, чтобы либо загрузить двоичный файл во временную таблицу как двоичный двоичный объект, либо как строку 0x -hex.
Что же тогда произойдет, когда вы обновите функцию / хранимый процесс? Вы не можете обновить какую-то сборку, от которой зависит другая сборка (я не могу вспомнить, было ли это) s только при изменении сигнатуры функции ..). Я думаю, мы всегда отбрасываем все sp / func / assys перед загрузкой новой версии какой-либо сборки.
Интеграция системы сборки и справочника - это идиотизм. Когда вы добавляете ссылку на sqlclr, эта dll должна быть развернута в SQLS. VS скопирует эту dll из SQLS в каталог obj / sqlclr для этого проекта и будет использовать его оттуда. Когда вы затем собираете этот проект с помощью системы сборки TFS, для успешной сборки у вас должна быть эта dll. (Существуют обходные пути, связанные с использованием совместно используемого сервера SQLS, но ...).
Когда SQLS имеет развернутые производственные библиотеки DLL, VS не сможет развернуть новые библиотеки DLL. Решение - отказаться от производственных dll.
Заставить отладчик работать с SQLCLR - это сука. Чаще всего нас сбивает с толку, если наше имя пользователя домена (DOMAIN \ username) не находится в группе sqladmin (или какой-то другой). Очень мало советов о том, что VS / SQLS сообщает вам, что не так и почему не удается достичь точки останова.
Тогда, даже когда вы пишете C #, вы в конечном итоге пишете SQL в виде жестко закодированных строк. Я не знаю, существуют ли какие-нибудь помощники, чтобы избежать этой чуши, для sqlclr нет nhibernate / sqlalchemy. Это в основном в SP, которым необходимо обрабатывать много строк и т. Д. На функции это в меньшей степени влияет.
Это также означает, что если вы используете nhibernate или что-то подобное в слое BL, вы, вероятно, не сможете повторно использовать его в слое sqlclr, и вы будете дублировать классы. Создание экземпляров объектов из SqlReader было очень, очень, очень неприятным занятием в 2009 году. То, что думала MS, выходит за рамки меня, невероятная чушь.
В целом, я думаю, что SQLCLR намного лучше, чем T-SQL, но в некоторых ситуациях заканчивается просто кодировать T-SQL SP, потому что он
Основные из них, которые я вижу:
- Не относящиеся к базе данных, например, права UNSAFE на запись в реестр, остановку / запуск служб и т. Д.
- Избегает написания SQL
- Труднее настроить, trace and tweak
Есть история о том, как MS пыталась реализовать "дата" и "время" как типы данных CLR для SQL Server 2005, но безуспешно ... (Изак Бен-Ган на семинаре в 2004 году)
Одна из проблем, с которыми я столкнулся , заключается в том, что контекстное соединение ведет себя не так, как это имеет смысл (как представляет связанный вопрос о SO)
Тем не менее, я считаю, что CLR великолепен.