SQL Server - Использование интеграции CLR для использования веб-службы

Question

В Интернете есть несколько учебных пособий , в которых описывается использование веб-службы с использованием интеграции CLR в SQL Server 2005. Для большинства процесс кажется довольно запутанным. Я столкнулся с несколькими проблемами, включая необходимость изменить уровень доверия к моей базе данных и использование инструмента sgen для создания статической сборки XmlSerializer; и я до сих пор не получил правильную работу ... (я уверен, что мне просто нужно потратить немного больше времени и энергии)

Каковы последствия для безопасности, производительности и обслуживания при переходе на этот тип архитектуры? Это, вероятно, будет довольно интенсивно используемый процесс, и простота обслуживания является относительно важной.

У меня есть свобода выбора, интегрировать ли это в SQL Server как UDF, или это будет автономная библиотека .NET для консольных / веб-приложений. Стоит ли интегрировать SQL CLR с внешними сборками?

Answer 1

Короткий ответ: нет, SQL CLR Integration, вероятно, не стоит проблем.

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

Во-вторых, как вы указали, вам нужно изменить безопасность, открывая потенциальные риски.

Используйте отдельное приложение для загрузки данных на ваш сервер. У вас будет больше контроля, меньше риска и намного проще.

Answer 2

Я думаю, что вы ответили на свой вопрос, лично я нахожу, что все, что вызывает WebService, больше, чем просто лучше, подходит для существования вне SQL Server. Сложности, повышенный уровень доверия и, как вы упомянули, общий запутанный процесс усложняют документирование и поддержание решения.

Answer 3

Я выполняю процедуры clr, которые вызывают веб-сервисы как в Exchange, так и в AD, и я согласен с постами выше. Это работает, но мы быстро столкнулись с проблемами нехватки памяти из-за особого способа обработки памяти в CLR внутри сервера sql. Как вы можете себе представить, производительность подходит для небольших запросов, но не масштабируется вообще.

Как правило, производительность вашей базы данных определяет производительность вашего приложения, и я думаю, что размещение такой логики в вашей базе данных - нет-нет, если вы не имеете полного контроля над тем, что делаете.

Используйте CLR для простых манипуляций с текстом и других вычислений, которые не зависят от внешних ресурсов.