CRL ou T-SQL, à  chacun sa spécialité (4)

chaque itération les valeurs de l’enregistrement courant au paramètre de sortie. Autrement dit, il s’agit d’une logique d’agrégation itérative simple. L’auteur de la procédure originale souhaitait probablement illustrer la syntaxe de création d’une procédure stockée CLR et l’utilisation des paramètres de sortie.

Néanmoins, une telle logique constitue un exemple classique de ce qu’il ne faut jamais faire dans .NET sans une bonne raison, par exemple si vous devez effectuer des calculs complexes (ou des manipulations plus judicieuses avec le code CLR) pour chaque enregistrement dans l’objet reader. Je présente ici des excuses à tous pour avoir signalé du code mal à propos dans la documentation en ligne, mais il est vital de comprendre qu’il s’agit précisément du type d’activité nécessitant T-SQL, pour des raisons de performances et de simplicité. Pour tester la procédure CLR, exécutez le code suivant :
DECLARE @sumqty AS BIGINT,
@sumprice AS MONEY;
EXEC dbo.usp_OrderDetailsTotals
@sumqty = @sumqty OUTPUT;
@sumprice = @sumprice OUTPUT;
SELECT @sumqty AS sumqty,
@sumprice AS sumprice;

Sur mon système, ce code s’est exécuté en un peu plus de 4 secondes. Dans T-SQL, vous n’avez pas besoin d’une procédure stockée pour cette tâche. La requête simple suivante suffit :
SELECT SUM(Quantity) AS sumqty,
SUM(UnitPrice) AS sumprice
FROM dbo.OrderDetails;

Cette requête s’est exécutée en une demi-seconde environ sur mon système, soit 8 fois plus rapidement qu’avec le code CLR. En utilisant une requête basée sur les ensembles, vous permettez à l’optimiseur d’accomplir ce qu’il fait de mieux : choisir un plan d’exécution efficace pour votre requête. Si vous employez le code interactif dans l’implémentation CLR, vous imposez un plan d’exécution spécifique et induisez le temps de traitement nécessaire à une manipulation enregistrement par enregistrement.