Каковы возможные проблемы с интеграцией CLR в Sqlserver

Question

Я прочитал статью об использовании интеграции CLR в sqlserver, и мне было интересно, какие могут быть потенциальные проблемы, если таковые имеются. Я думал использовать это для проверки потенциальности плохих данных в устаревшей базе данных. Например, имя человека в столбце номера телефона.

Edit: Я не думаю, что есть какие-либо проблемы, но это не то, о чем я вижу много дискуссий, и хочу убедиться, что я не открываю червячных червей, которые позже вызовут проблемы. Причина, по которой я спрашиваю, заключается в том, что мой администратор БД смотрел на меня так, будто я сошел с ума, когда спросил об этом.

Answer 1

Интеграция CLR в SQL Server сама по себе не является нестабильной. В качестве доказательства я укажу вам на тот факт, что в SQL Server 2008 группа типов данных system была реализована как типы данных CLR, например, новые типы geography и geometry . Таким образом, CLR считался достаточно безопасным, чтобы на нем могли основываться новые основные функции.

Тем не менее, CLR привносит в программирование на SQL совершенно новый арсенал, чтобы выстрелить себе в ногу. Вы можете запускать потоки, блокировать связь IPC (события, мьютексы, семафоры), подключаться извне и ждать ввода-вывода, чтения / записи в память, вызывать различные Win32 APIS и вообще вести себя безрассудно и нанести ущерб. Старое программирование на T-SQL требовало гораздо большего хакерского таланта для достижения того же.

Вы ищете реализацию нового типа данных, который демонстрирует хорошее, ограниченное поведение, такое как, скажем, проверка поля регулярным выражением? Преуспевать. Вы хотите делать запросы к веб-сервисам из среды CLR, размещенной на SQL? У вас есть, и вы заслужите все, что вы получите!

Практическое правило: если ваша сборка будет загружаться и проверяться без достоверных требований (без EXTERNAL_ACCESS, без UNSAFE), то с вами все будет в порядке. Конечно, вы по-прежнему можете писать циклы while (1) {;} в SAFE-сборках, но в этом случае T-SQL может сохранять хранимые процедуры ...

Answer 2

Одной из проблем является то, как вы получаете CLR (производственные) экземпляры на сервер. Например, в нашей компании есть клиенты, которые не предоставляют нам доступ к своим SQL-серверам, но используют удаленное соединение через SSMS. Так что нет локального пути, из которого вы можете развернуть свою сборку DLL. Решение состоит в том, чтобы загрузить двоичный файл во временную таблицу в виде двоичного двоичного объекта или в виде строки 0x -hex.

Тогда что происходит, когда вы обновляете функцию / сохраненный процесс? Вы не можете обновить какую-либо сборку, от которой зависит другая сборка (я не могу вспомнить, если это происходит только в случае изменения сигнатуры функции ..) Я думаю, что мы всегда отбрасываем все sp / func / assys, прежде чем загружать новую версию любой сборки.

Интеграция системы сборки / эталонной системы идиотская. Когда вы добавляете ссылку на sqlclr, вы должны иметь эту dll, развернутую в SQLS. VS скопирует эту dll из SQLS в каталог obj / sqlclr для этого проекта и затем будет использовать его оттуда. Когда вы затем строите этот проект с помощью системы сборки TFS, у вас должна быть эта dll для успешной сборки. (Существуют обходные пути, связанные с общим сервером SQLS, но ..).

Когда в SQLS развернуты производственные библиотеки DLL, VS не сможет развернуть новые библиотеки DLL. Решение состоит в том, чтобы сократить производство DLLS.

Получение отладчика для работы с SQLCLR - сука. Мы чаще всего сталкиваемся с тем, что имя нашего домена (DOMAIN \ username) не входит в группу «sqladmin» (или что-то подобное). Существует очень мало советов о том, что VS / SQLS говорит вам, что не так и почему он не может достичь точки останова.

Тогда даже когда вы пишете на C #, вы в конечном итоге пишете SQL в жестко закодированных строках. Я не знаю, существуют ли какие-то помощники, чтобы избежать этой ерунды, для sqlclr нет nhibernate / sqlalchemy. Это в основном в SP, которые должны обрабатывать много строк / и т.д. Это меньше влияет на функции.

Это также означает, что если вы используете nhibernate или что-то подобное в вашем слое BL, вы, вероятно, не сможете повторно использовать его в слое sqlclr и будете дублировать классы. Создание экземпляров объектов из SqlReader очень, очень, очень раздражает в 2009 году. То, о чем думали MS, выше меня, невероятная чушь.

В целом, я думаю, что SQLCLR намного лучше, чем T-SQL, но в некоторых ситуациях в конечном итоге просто кодируется T-SQL SP, потому что это меньше беспокоит.

Answer 3

Основные из них, которые я вижу:

• Не относящиеся к базе данных вещи, например, НЕПРАВИЛЬНЫЕ права на запись в реестр, остановку / запуск служб и т. Д.
• Предотвращение написания SQL
• Сложнее настраивать, отслеживать и настраивать

Существует история о том, что MS пытается реализовать "дату" и "время" как типы данных CLR для SQL Server 2005, но не удается ... (Ицак Бен-Ган всеминар в 2004 году)

Answer 4

Одна из проблем, с которыми я столкнулся , заключается в том, что контекстное соединение не ведет себя таким образом, который имеет смысл (как представляет связанный вопрос в SO)

Несмотря на это, я думаю, что CLR великолепен.