SQLCLR est assez rapide. Utilisez-le si vous avez clairement besoin d'exécuter du code CLR dans T-SQL. Par exemple, supposons que vous écrivez une fonction SQLCLR avec la signature:
SqlString Hash(SqlString input)
et vous parvenez à obtenir tout en cours d'exécution comme il le devrait. Vous pouvez exécuter la requête suivante:
IF EXISTS(SELECT * FROM Users WHERE HashedPassword = dbo.Hash(@userPassword) AND UserName = @userName)
BEGIN
SELECT 'You''re alright, Jack.';
END
ELSE
BEGIN
SELECT 'Bogus.';
END
Si vous parvenez à hachage du champ de mot de passe hypothétique dans votre application, vous êtes mieux de le faire dans l'application et passez la valeur de hachage dans SQL Server pour exécuter une requête comme ceci:
SELECT *
FROM User
WHERE UserName = @userName AND HashedPassword = @hashedPassword
cela vaut mieux pour quelques raisons:
- Vous ne mettez pas la logique métier dans SQL Server, où il sera difficile de tester.
- La requête elle-même est beaucoup moins compliquée, donc SQL Server fera moins de travail, et sera donc plus rapide.
- La définition de SQLCLR vers le haut peut être pénible (SQLCLR est désactivé par défaut). Le déploiement de vos assemblys dans SQL Server peut être difficile, surtout si vous n'avez pas directement accès au serveur de production.
- Si vous n'utilisez pas SQLCLR, lorsque vous mettez à jour/déployez votre application, vous n'avez pas besoin de vous souvenir de mettre à jour/déployer les éléments CLR dans SQL Server. Cela réduit vos efforts de maintenance.
Les nouvelles entités spatiales ont été implémentées en utilisant le CLR. Au moins, cela montre que MS était assez confiant dans le CLR pour implémenter une nouvelle fonctionnalité majeure qui devait aussi bien fonctionner. – AaronLS
Aucune des méthodes de chiffrement intégrées n'est-elle appropriée? –
Will, Je dois implémenter le chiffrement SHA256 ou supérieur, qui, pour autant que je sache, ne sont pas disponibles avec la version rétractable de SQL Server 2008. – ElHaix