Les procédures stockées CLR sont-elles préférées aux procédures stockées TSQL dans SQL 2005+ ?

Question

Mon point de vue actuel est non, préférez les procédures stockées Transact SQL car elles constituent une option plus légère et (éventuellement) plus performante, tandis que les procédures CLR permettent aux développeurs de faire toutes sortes de méfaits.

Cependant, récemment, j'ai eu besoin de déboguer certains processus stockés TSQL très mal écrits.Comme d'habitude, j'ai trouvé de nombreux problèmes dus au fait que le développeur d'origine n'avait aucune véritable expérience TSQL, ils étaient axés sur ASP.NET / C#.

Ainsi, l'utilisation des procédures CLR fournirait d'une part un ensemble d'outils beaucoup plus familiers à ce type de développeur, et d'autre part, les fonctionnalités de débogage et de test seraient plus puissantes (c'est-à-dire Visual Studio au lieu de SQL Management Studio).

Je serais très intéressé de connaître votre expérience car il semble que ce ne soit pas un choix simple.

Answer 1

Il existe des emplacements pour T-SQL et CLR bien écrits et bien pensés.Si une fonction n'est pas appelée fréquemment et si elle nécessite des procédures étendues dans SQL Server 2000, CLR peut être une option.Il peut également être intéressant d'exécuter des éléments tels que le calcul juste à côté des données.Mais résoudre les mauvais programmeurs en intégrant de nouvelles technologies semble être une mauvaise idée.

Answer 2

Les procédures stockées CLR ne sont pas destinées à remplacer les requêtes basées sur des ensembles.Si vous devez interroger la base de données, vous devrez toujours insérer SQL dans votre code CLR, comme s'il était intégré dans du code normal.Ce serait une perte d’effort.

Les procédures stockées CLR servent à deux choses principales :1) interaction avec le système d'exploitation, comme lire un fichier ou déposer un message dans MSMQ, et 2) effectuer des calculs complexes, surtout lorsque vous disposez déjà du code écrit dans un langage .NET pour effectuer le calcul.

Answer 3

L'hébergement du CLR dans SQL Server est destiné à donner aux développeurs de bases de données options plus flexibles dans la manière dont ils cherchaient à accomplir leurs tâches.Comme d'autres l'ont mentionné, SQL est idéal pour les opérations et les modifications sur ensembles de données.Quiconque a réalisé un développement approfondi d'applications de grande envergure avec des règles métier/domaines complexes vous le dira probablement : essayer d'appliquer certaines de ces règles en utilisant du SQL pur (parfois dans une seule requête de macro) peut devenir vraiment cauchemardesque.

Certaines tâches sont mieux gérées de manière procédurale ou OO.En ayant le choix d'utiliser le code .NET pour décomposer la séquence logique, les opérations de requête peuvent devenir plus faciles à lire et à déboguer.Après avoir utilisé des procédures stockées CLR, je peux vous dire que le fait de passer par le débogueur facilite vraiment le suivi de ce qui se passe au niveau de la base de données.

Juste un exemple, nous utilisons fréquemment ici les procédures stockées CLR comme « passerelle » pour les requêtes de recherche dynamiques.Dites une demande de recherche pouvant contenir jusqu'à 30 paramètres de recherche différents.Les utilisateurs n'utilisent évidemment pas les 30, donc la structure de données transmise aura 30 paramètres mais principalement DBNULL.Le côté client a pas d'option pour générer une instruction dynamique, pour des raisons évidentes de sécurité.L'instruction dynamique qui en résulte est générée en interne sans crainte d'« extras » externes.

Answer 4

En général, vous utilisez le CLR si vous avez quelque chose qui n'a pas beaucoup besoin d'interagir avec la base de données.Supposons donc que vous analysiez ou décodiez une valeur.C'est plus facile à faire dans le CLR, puis à renvoyer la valeur.

Essayer de faire une requête complexe dans le CLR n'est tout simplement pas la voie à suivre.

BTW, cela n’a pas changé non plus en 2008.

Answer 5

Je crois que ces deux-là ne sont pas équivalents...aptes à s’affronter.
L'intégration CLR est censée éliminer progressivement les « procédures stockées étendues » d'autrefois. Nous en avons quelques-uns sur notre lieu de travail...essentiellement des blocs de traitement/logique sur des données SQL qui étaient trop difficiles/impossibles à réaliser via des procédures stockées DB conventionnelles/T SQL.Ils l'ont donc écrit sous forme de procédures stockées étendues dans des DLL C++ qui peuvent être invoquées de la même manière.Ils ont désormais été progressivement supprimés et l'intégration CLR les remplace.

• Procédures stockées dans la base de données :si cela peut être fait dans les processus stockés T SQL, faites-le.
• Procédures stockées CLR :si la logique est trop complexe ou fastidieuse à faire via T SQL...si c'est quelque chose qui nécessitera moins de lignes de code CLR pour y remédier (manipulation de chaînes, tri ou filtrage complexe/personnalisé, etc.), utilisez cette approche.

Answer 6

Mis à part l'accès au système de fichiers (où les procédures CLR ont un avantage très prononcé), j'utiliserais les procédures T-SQL.Si vous avez des calculs particulièrement complexes, vous pouvez éventuellement mettre cette pièce dans un CLR. fonction et appelez ceci depuis votre proc (c'est dans les udf que j'ai trouvé que l'intégration CLR brille vraiment).Ensuite, vous bénéficiez des avantages de l'intégration CLR pour cette partie particulière de votre tâche, mais conservez autant que possible votre logique de procédure stockée dans la base de données.

Answer 7

Compte tenu de ce que vous avez dit, je préférerais que les développeurs soient correctement formés à t-SQl et aux bases de données en général plutôt que de leur permettre de créer peut-être beaucoup plus de dommages aux performances en leur permettant d'effectuer des tâches t-sql dans les CLR.Les développeurs qui ne comprennent pas les bases de données utilisent cela comme excuse pour éviter de faire les choses de la manière la plus efficace pour les performances des bases de données, car ils souhaitent emprunter ce qu'ils considèrent comme la voie la plus simple.

Answer 8

Cela dépend toujours du bon outil pour le travail, cela dépend donc vraiment de ce que vous essayez d'accomplir.

Cependant, en règle générale, vous avez raison de dire que les procédures CLR ont une surcharge plus importante et ne seront jamais exécutées sur des opérations définies comme T-SQL.Ma ligne directrice est de tout faire en T-SQL, à moins que ce dont vous avez besoin ne devienne trop compliqué en T-SQL.Ensuite, essayez plus fort de faire fonctionner l’approche T-SQL.:-)

Les processus CLR sont excellents et ont leur place, mais leur utilisation devrait être l'exception et non la règle.

Answer 9

La documentation en ligne de SQL Server page sur le sujet énumère ces avantages :

• Un meilleur modèle de programmation. Les langages .NET Framework sont à bien des égards plus riches que Transact-SQL, offrant des constructions et des fonctionnalités auparavant non disponibles pour les développeurs SQL Server.Les développeurs peuvent également exploiter la puissance de la bibliothèque .NET Framework, qui fournit un ensemble complet de classes pouvant être utilisées pour résoudre rapidement et efficacement les problèmes de programmation.

• Amélioration de la sûreté et de la sécurité. Le code managé s'exécute dans un environnement d'exécution en langage commun, hébergé par le moteur de base de données.SQL Server exploite cela pour fournir une alternative plus sûre et plus sécurisée aux procédures stockées étendues disponibles dans les versions antérieures de SQL Server.

• Possibilité de définir des types de données et des fonctions d'agrégation. Les types définis par l'utilisateur et les agrégats définis par l'utilisateur sont deux nouveaux objets de base de données gérés qui étendent les capacités de stockage et d'interrogation de SQL Server.

• Développement rationalisé grâce à un environnement standardisé. Le développement de bases de données est intégré aux futures versions de l'environnement de développement Microsoft Visual Studio .NET.Les développeurs utilisent les mêmes outils pour développer et déboguer des objets et des scripts de base de données que pour écrire des composants et des services .NET Framework de niveau intermédiaire ou client.

• Potentiel d’amélioration des performances et de l’évolutivité. Dans de nombreuses situations, les modèles de compilation et d'exécution du langage .NET Framework offrent des performances améliorées par rapport à Transact-SQL.

Answer 10

Nous avons rencontré une situation avec une fonction CLR qui a été appelée des milliers de fois dans une procédure SQL standard.Il s'agissait d'une procédure pour importer des données depuis un autre système.La fonction a validé les données et a bien géré les valeurs nulles.

Si nous effectuions l'opération en TSQL, le processus se terminait en 15 secondes environ.Si nous utilisions la fonction CLR, le processus se terminait en 20 à 40 minutes.La fonction CLR avait l'air plus élégante, mais autant que nous puissions en juger, il y avait un démarrage au démarrage pour chaque utilisation de la fonction CLR.Donc, si vous effectuez une opération importante à l'aide d'une fonction CLR, c'est très bien car le temps de démarrage est petit par rapport au temps de l'opération.Ou si vous appelez la fonction CLR un nombre modeste de fois, le temps de démarrage total pour tous les appels de la fonction sera réduit.Mais attention aux boucles.

De plus, pour des raisons de maintenabilité, il est préférable de ne pas avoir plus de langues que ce dont vous avez réellement besoin.

Answer 11

J'ajouterais quelques raisons d'utiliser CLR qui n'ont peut-être pas été mentionnées.

• Remplacez et étendez les fonctions SQL de base de requête, sans requête et scalaires.
  A) Les rapports d'erreurs et les alertes peuvent être intégrés en fonction des exigences définies.B) Définissez facilement les niveaux de débogage.C) Permettre un moyen plus simple d'interagir avec des serveurs SQL étrangers
• Déplacez le code existant vers un environnement géré.

Answer 12

J'ai posté la réponse suivante à une question similaire : Avantage de SQL SERVER CLR.J'ajouterai cependant ici que C# / VB.net / etc est un langage avec lequel quelqu'un est plus à l'aise que T-SQL ne devrait le faire. pas être une raison d'utiliser SQLCLR sur T-SQL.Si quelqu'un ne sait pas comment accomplir quelque chose en T-SQL, demandez d'abord de l'aide pour trouver une solution T-SQL.S'il n'en existe pas, alors suivez la route CLR.

---

L'intégration SQLCLR/CLR dans SQL Server n'est qu'un autre outil pour aider à résoudre certains problèmes (pas tous).Il y a certaines choses qu'il fait mieux que ce qui peut être fait en T-SQL pur, et certaines choses ne peuvent être faites que via SQLCLR.J'ai écrit un article pour SQL Server Central, Escalier vers SQLCLR niveau 1 :Qu’est-ce que SQLCLR ? (une inscription gratuite est requise pour y lire des articles), qui répond à cette question.Les bases sont (voir l'article lié pour plus de détails) :

• Fonctions de diffusion en continu (sTVF)
• SQL dynamique (dans les fonctions)
• Meilleur accès aux ressources externes / Remplacer xp_cmdshell
  • La transmission des données est plus facile
  • Récupérer plusieurs colonnes d’un ensemble de résultats est plus facile
  • Aucune dépendance externe (par ex.7zip.exe)
  • Meilleure sécurité via l'usurpation d'identité
• Capacité à multithread
• Gestion des erreurs (dans les fonctions)
• Agrégats personnalisés
• Types personnalisés
• Modifier l'état (au sein d'une fonction et sans OPENQUERY / OPENROWSET)
• Exécuter une procédure stockée (lecture seule ;au sein d'une Fonction et sans OPENQUERY / OPENROWSET)
• Performance (note: c'est pas c'est-à-dire dans tous les cas, mais certainement dans certains cas en fonction du type et de la complexité de l'opération)
• Peut capturer la sortie (c.-à-d.ce qui est envoyé à l'onglet Messages dans SSMS) (par ex. PRINT et RAISERROR avec un gravité = 0 à 10) -- J'ai oublié de mentionner celui-là dans l'article ;-).

Une autre chose à considérer est qu'il est parfois avantageux de pouvoir partager du code entre l'application et la base de données afin que la base de données ait un aperçu de certaines logiques métier sans avoir à créer des écrans personnalisés uniquement internes pour accéder au code de cette application.Par exemple, j'ai travaillé sur un système qui importait des fichiers de données de clients, utilisait un hachage personnalisé de la plupart des champs et enregistrait cette valeur dans la ligne de la base de données.Cela permettait de sauter facilement des lignes lors de l'importation à nouveau de leurs données, car l'application hacherait les valeurs du fichier d'entrée et les comparerait à la valeur de hachage stockée sur la ligne.S'ils étaient identiques, nous savions instantanément qu'aucun des champs n'avait changé, nous sommes donc passés à la ligne suivante, et il s'agissait d'une simple comparaison INT.Mais cet algorithme pour effectuer le hachage était uniquement dans le code de l'application, que ce soit pour déboguer un cas client ou pour rechercher des moyens de décharger certains traitements vers les services back-end en signalant les lignes comportant au moins un champ avec des modifications (modifications provenant de notre application au lieu de rechercher des modifications dans un fichier d'importation plus récent), je ne pouvais rien faire.Cela aurait été une excellente opportunité d'avoir un peu de logique métier assez simple dans la base de données, même si ce n'était pas pour un traitement normal ;avoir ce qui équivaut à une valeur codée dans la base de données sans pouvoir en comprendre la signification rend la résolution des problèmes très difficile.

Si vous souhaitez voir certaines de ces fonctionnalités en action sans avoir à écrire de code, la version gratuite de SQL# (dont je suis l'auteur) possède des fonctions RegEx, des agrégats personnalisés (UDA), des types personnalisés (UDT), etc.