Вопрос, как указал Ремус, слишком общий, чтобы получить ответ, так как ответ зависит от контекста того, какая функциональность будет использоваться и как она будет использоваться.
Относительно "безопасности":
Если вы спрашиваете о чем-либо, что можно сделать в сборке, помеченной значком PERMISSION_SET = SAFE, то я не смог найти никаких проблем, которые когда-либо могли бы найти. И SQLCLR "безопаснее", чем использование xp_cmdshellили замечательных (это был сарказм) процедур sp_OA*(или даже расширенных хранимых процедур, но, надеюсь, никто из них больше не создаст).
Если вы хотите получить представление о том, что «SAFE» означает в практическом плане, см. Эту статью: Лестница к SQLCLR Уровень 3: Безопасность (Общие и SAFE сборки) (требуется бесплатная регистрация).
Если вы спрашиваете обо всем, что можно сделать в сборке, помеченной значком PERMISSION_SET = EXTERNAL_ACCESS, то, безусловно, существуют риски, опять же, в зависимости от того, какая функциональность используется. Если вы пишете подпрограмму для чтения каталогов и имен файлов (то есть только для чтения), то это просто вопрос того, что следует видеть, а не видеть. Если вы пишете код, позволяющий удалить файл, риск возрастает. Но то, что можно сделать с этими внешними ресурсами, контролируется:
- используете ли вы олицетворение или нет:
- без олицетворения означает, что доступ к внешним ресурсам осуществляется через учетную запись «Вход в систему» службы SQL Server. К чему бы ни имел доступ этот аккаунт, ваша функция SQLCLR сможет это сделать.
- использование олицетворения означает, что имя входа в SQL Server, на котором выполняется эта функция, если это имя входа соответствует имени входа Windows, может делать все, что разрешено этому конкретному имени входа Windows. Если имя входа в SQL Server является именем входа SQL Server, то попытка использовать олицетворение приведет к ошибке.
- Какие разрешения установлены на внешнем ресурсе. Для доступа к файловой системе это контролируется через ACL на дисках NTFS.
Если вы спрашиваете о чем-либо, что может быть сделано в сборке, отмеченной PERMISSION_SET = UNSAFEэто довольно открытый. Многие функциональные возможности считаются пригодными только для сборок UNSAFE, поскольку они представляют собой проблемы стабильности и / или согласованного поведения, а не безопасности или производительности. Например, в сборке UNSAFE возможно иметь доступную для записи статическую переменную. Обычно это не очень хорошая вещь, так как классы SQLCLR совместно используются всеми сеансами. Если вы намереваетесь обмениваться данными в памяти по всем сеансам и запланировали условия гонки (и провели много испытаний), то вы должны быть в порядке, ожидая такого поведения. Но если вы просто хотели, чтобы доступная для записи статическая переменная кэшировала значение для определенного сеанса, чтобы не приходилось искать его снова или вычислять снова, и не знали, что другие сеансы читают это значение и, возможно, перезаписывают его, ну, это было бы проблемой.
Но если вы беспокоитесь о том, что кто-то пишет в Реестр, но при этом у вас нет кода, который действительно пишет в Реестр, то вам, вероятно, не нужно беспокоиться об этом ;-).
Если вы хотели бы получить представление о том, как EXTERNAL_ACCESS и UNSAFE работают в практическом плане, и разницу между настройкой TRUSTWORTHY ON(не желательно) и использованием асимметричного входа на основе ключа или сертификата, см. Эту статью: Лестница к SQLCLR уровня 4: Безопасность (ВНЕШНИЕ и БЕЗОПАСНЫЕ сборки) (требуется бесплатная регистрация).
Относительно «Производительности»:
Это все зависит от того, что вы пытаетесь сделать и как вы это делаете. Есть некоторые вещи, которые намного быстрее в SQLCLR, и некоторые вещи, которые медленнее. Но, как и в случае с T-SQL, можно взять несколько простых и / или эффективных задач и сделать их сложными и / или неэффективными из-за неправильного выполнения действий. Но использование SQL CLR по своей природе не медленнее.