SQL Server - Использование интеграции CLR для использования веб-службы
В сети есть несколько учебные пособия, которые описывают использование веб-службы с использованием интеграции SQL Server 2005 со средой CLR. Большинству этот процесс кажется довольно запутанным. Я столкнулся с несколькими проблемами, включая необходимость изменения уровня доверия моей базы данных и использование инструмента sgen для создания статической сборки XmlSerializer; и я до сих пор не наладил его работу ... (я уверен, что мне просто нужно потратить на это немного больше времени и энергии)
Каковы последствия перехода на этот тип архитектуры с точки зрения безопасности, производительности и обслуживания? Скорее всего, это будет довольно часто используемый процесс, и простота обслуживания относительно важна.
У меня действительно есть свобода выбора, интегрировать ли это в SQL Server как UDF или сделать это отдельной библиотекой .NET для консольных / веб-приложений. Стоит ли проблема интеграции SQL CLR с внешними сборками?
Ответы 3
Я думаю, вы ответили на свой вопрос, я лично считаю, что все, что вызывает WebService, более чем вероятно лучше подходит для существования ВНЕ SQL Server. Сложности, повышенный уровень доверия и, как вы упомянули, в целом запутанный процесс затрудняют документирование и сопровождение решения.
Короткий ответ: нет, интеграция SQL CLR, вероятно, не стоит проблем.
В более длинном ответе есть несколько моментов, начиная с программирования CLR в базе данных. Это прекрасный инструмент при правильном использовании, но он увеличивает потребление памяти и может привести к проблемам с производительностью, если все сделано неправильно. Я использую его в своей базе данных для очень специализированных функций, таких как добавление возможности RegEx, но он используется экономно, с хорошо протестированным кодом, чтобы предотвратить возникновение как можно большего количества проблем.
Во-вторых, как вы отметили, вы должны изменить систему безопасности, открывая потенциальные риски.
Используйте автономное приложение для загрузки данных на свой сервер. У вас будет больше контроля, меньше риска и вам будет намного легче.
Я выполнял процедуры clr, которые вызывают веб-службы как в Exchange, так и в AD, и я согласен с сообщениями выше. Это работает, но мы быстро столкнулись с проблемами нехватки памяти из-за особого способа обработки памяти в CLR на сервере sql. Как вы понимаете, производительность подходит для небольших запросов, но не масштабируется вообще.
Как правило, производительность вашей базы данных определяет производительность вашего приложения, и я думаю, что размещение такой логики в вашей базе данных является недопустимым, если у вас нет полного контроля над тем, что вы делаете.
Используйте CLR для простых текстовых манипуляций и других вычислений, не зависящих от внешних ресурсов.