Servidor SQL: uso de la integración CLR para consumir un servicio web

Question

Hay unos pocos tutorials en la web que describen consumir un servicio web utilizando la integración CLR de SQL Server 2005. Para la mayoría, el proceso parece bastante intrincado. Me he encontrado con varios problemas, incluida la necesidad de cambiar el nivel de confianza de mi base de datos, y el uso de la herramienta sgen para crear un ensamblado XmlSerializer estático; y todavía no lo he hecho funcionar bien ... (estoy seguro de que solo necesito ponerle un poco más de tiempo y energía)

¿Cuáles son las implicaciones de seguridad, rendimiento y mantenimiento al ir a este tipo de arquitectura? Es probable que este sea un proceso bastante utilizado, y la facilidad de mantenimiento es relativamente importante.

Tengo libertad para elegir integrar esto en SQL Server como una UDF, o hacer que sea una biblioteca .NET independiente para aplicaciones de consola/web. ¿Vale la pena la integración CLR de SQL con ensamblajes externos?

Answer 1

Creo que ha respondido a su propia pregunta, personalmente encuentro que cualquier cosa que llame a un servicio web es más que probable que exista para existir FUERA de SQL Server. Las complicaciones, los niveles de confianza elevados y, como mencionó, el proceso enrevesado general hace que sea una solución difícil de documentar y difícil de mantener.

Answer 2

La respuesta corta es, no, SQL CLR La integración probablemente no valga la pena.

La respuesta más larga tiene varios puntos, comenzando con la programación de CLR en la base de datos. Es una buena herramienta, cuando se usa correctamente, pero aumenta el consumo de memoria y puede provocar problemas de rendimiento si no se realiza correctamente. Lo uso en mi base de datos para una funcionalidad muy especializada, como agregar la capacidad de RegEx, pero se usa con moderación, con un código bien probado para evitar que surjan tantos problemas como sea posible.

Una segunda es que, como ha señalado, debe modificar la seguridad, lo que abre riesgos potenciales.

Utilice una aplicación independiente para cargar los datos en su servidor. Tendrás más control, menos riesgos y mucho más tiempo para hacerlo.

Answer 3

He estado haciendo clr procedimientos que llama a los servicios web tanto en Exchange y AD y estoy de acuerdo con las publicaciones anteriores. Funciona, pero rápidamente nos topamos con problemas de falta de memoria debido a la manera especial en que se maneja la memoria en CLR dentro del servidor sql. Como se puede imaginar, el rendimiento está bien para pequeñas consultas, pero no escala en absoluto.

En general, el rendimiento de su base de datos determina el rendimiento de su aplicación y creo que poner esa lógica en su base de datos es un no-no si no tiene el control total de lo que está haciendo.

Utilice CLR para manipulaciones de texto simples y otros cálculos que no dependen de recursos externos.