SQL Server - Utilisation de l'intégration CLR pour consommer un service Web

Question

Il existe quelques tutorials sur le Web qui décrivent la consommation d'un service Web à l'aide de l'intégration CLR de SQL Server 2005. Pour le plus, le processus semble assez compliqué. J'ai rencontré plusieurs problèmes, notamment la nécessité de modifier le niveau de confiance de ma base de données et l'utilisation de l'outil sgen pour créer un assemblage XmlSerializer statique; et je ne l'ai toujours pas fait fonctionner correctement ... (Je suis sûr que j'ai juste besoin d'y mettre un peu plus de temps et d'énergie)

Quelles sont les implications en termes de sécurité, de performances et de maintenance lorsque vous y accédez type d'architecture? Ce processus serait probablement très utilisé et la facilité d'entretien est relativement importante.

Je suis libre de choisir d'intégrer cette fonction dans SQL Server en tant que bibliothèque UDF ou de la faire en tant que bibliothèque .NET autonome pour les applications console/Web. L'intégration de SQL CLR avec des assemblages externes vaut-elle le coup?

Answer 1

Je pense que vous avez répondu à votre propre question, je trouve personnellement que tout ce qui appelle un WebService est plus que probablement mieux adapté pour exister en dehors de SQL Server. Les complications, les niveaux de confiance élevés et, comme vous l'avez mentionné, le processus complexe compliqué, rendent la solution difficile à documenter et difficile à maintenir.

Answer 2

La réponse courte est, non, l'intégration SQL CLR ne vaut probablement pas la peine.

La réponse la plus longue a plusieurs points, en commençant par la programmation CLR dans la base de données. C'est un bon outil, lorsqu'il est utilisé correctement, mais il augmente la consommation de mémoire et peut entraîner des problèmes de performance s'il n'est pas fait correctement. Je l'utilise dans ma base de données pour des fonctionnalités très spécialisées, telles que l'ajout de capacité RegEx, mais il est utilisé avec parcimonie, avec un code bien testé pour éviter autant de problèmes que possible de surgir. Une seconde est, comme vous l'avez souligné, que vous devez modifier la sécurité, ce qui ouvre des risques potentiels.

Utilisez une application autonome pour charger les données dans votre serveur. Vous aurez plus de contrôle, moins de risques et beaucoup plus de temps.

Answer 3

J'ai fait des procédures clr qui appelle des services web à la fois sur Exchange et AD et j'accepte les messages ci-dessus. Cela fonctionne, mais nous avons rapidement rencontré des problèmes de mémoire insuffisante en raison de la façon particulière dont la mémoire est gérée dans CLR à l'intérieur du serveur sql. Comme vous pouvez l'imaginer, la performance est bonne pour les petites requêtes, mais pas du tout.

En général, les performances de votre base de données déterminent les performances de votre application et je pense qu'une telle logique dans votre base de données est un non-non si vous n'avez pas un contrôle total sur ce que vous faites.

Utilisez CLR pour des manipulations de texte simples et d'autres calculs qui ne dépendent pas de ressources externes.