Comparer les extensions de langage SQL Server et SQL CLR
S’applique à : 
SQL Server 2019 (15.x) et versions ultérieures
Cet article compare les Extensions de langage SQL Server et le Common Language Runtime (CLR) natif. Il identifie les principales différences et vous aide à faire votre choix.
Les extensions de langage SQL Server sont une fonctionnalité de SQL Server utilisée pour l’exécution de code externe. Les données relationnelles peuvent être utilisées dans le code externe avec le framework d’extensibilité.
Le common language runtime (CLR) natif vous permet d’implémenter certaines des fonctionnalités de SQL Server avec les langages .NET. Le CLR fournit le code managé avec des services tels que l'intégration interlangage, la sécurité d'accès du code, la gestion de la durée de vie des objets et la prise en charge du débogage et des profils.
Les langages disponibles dans les Extensions de langage SQL Server ne constituent pas un remplacement direct pour SQL CLR. L’infrastructure d’extensibilité et les extensions de langage étendent la surface d’exposition de SQL Server et fournissent un environnement d’exécution pour les runtimes plus proches du moteur de base de données. Ils fournissent également une infrastructure open source qui peut être utilisée pour intégrer de nouveaux runtimes sans modification du moteur. Actuellement, la surface d’exposition est limitée à la procédure stockée système sp_execute_external_script.
Voici quelques-unes des principales différences entre les extensions de langage SQL et SQL CLR :
| Fonctionnalité | SQL CLR | Extensions de langage SQL |
|---|---|---|
| Plateforme prise en charge | Windows et Linux : Linux ne prend en charge que les assemblys SAFE. |
Windows et Linux : parité complète en termes de fonctionnalité. |
| Mode d’exécution | Dans processus | Hors processus |
| Isolation | Le code CLR s'exécute dans le processus du moteur, l'administrateur de l'instance doit faire confiance à tous les assemblys/tout le code. | L’exécution du runtime est en dehors du processus du moteur. Une isolation supplémentaire est fournie à l’aide de conteneurs d’applications dans Windows ou d’espaces de noms dans Linux. La communication réseau externe est également désactivée par défaut. |
| Syntaxe déclarative (T-SQL) | Types définis par l’utilisateur, agrégats définis par l’utilisateur, fonctions, procédures, déclencheurs. | Exécution ad hoc uniquement à l'aide de sp_execute_external_script. |
| Prise en charge DDL | CREATE ASSEMBLY pour charger le code utilisateur et définir d'autres objets (fonctions, procédures, déclencheurs de type défini par l'utilisateur, agrégats de type défini par l'utilisateur). |
CREATE EXTERNAL LANGUAGE, EXTERNAL LIBRARY pour gérer les extensions et les bibliothèques. |
| Prise en charge de la bibliothèque | Obtenu via des assemblys. | Les bibliothèques pour un runtime spécifique peuvent être utilisées (par exemple les packages R ou Python, les bibliothèques Java). |
| Runtimes pris en charge | .NET Framework | R, Python, Java, C# ou Bring your own runtime (BYOR). |
| Infrastructure OSS | N/A : peut être étendu par le biais d’assemblys .NET définis par l’utilisateur. | Oui : le kit SDK d’extension permet la création de nouvelles extensions ou l’intégration avec des runtimes sans modification du moteur. |
| Intégration QO | Intégration au niveau de l’opérateur pour différentes syntaxes, notamment le parallélisme. | Opérateur de script externe unique pour envoyer/recevoir les résultats et les données à partir des runtimes, cet opérateur prend en charge le parallélisme et l’exécution en mode batch. |
| Gouvernance des ressources | Aucun : peu de boutons en dehors du gouverneur de ressources. | Fournit un objet EXTERNAL RESOURCE POOL comme mécanisme distinct pour régir les ressources consommées par les scripts d'exécution/externes, les stratégies peuvent être définies pour les runtimes externes en plus de la charge de travail SQL. |
| Modèle d’autorisation | Contrôle au niveau de l’instance avec des objets au niveau de la base de données. | Contrôle au niveau de l’instance avec des objets au niveau de la base de données. |
| Performances | Le code SQL CLR offre généralement des performances d'extensibilité en raison de la nature de l'exécution. | Idéal pour l’exécution axée par lot. |
| Fonctionnalités de surveillance | sys.dm_clr* DMV et compteur d'analyseur de performances limité spécifique à SQL CLR. |
sys.dm_external* DMV, DMV de liste de ressources partagées, compteurs d'analyseur de performances JobObject. |
Quand utiliser les différents services
L’utilisation des extensions de langage ou du CLR dépend de vos scénarios et objectifs. Par exemple, si vous devez étendre la surface d'exposition T-SQL avec vos propres types ou agrégats, l'idéal est d'opter pour le CLR, car le type ou l'agrégat ne peut pas être défini à l'aide du mécanisme d'extensibilité. En revanche, si vous souhaitez utiliser l'expertise de la science des données existante dans votre organisation ou dans votre équipe, l'utilisation de l'intégration R/Python avec l'extensibilité est le meilleur choix.
De même, vos objectifs en matière de performances peuvent déterminer votre décision. L'implémentation d'une fonction regex en C# et l'utilisation de CLR est beaucoup plus rapide que l'utilisation de l'extensibilité pour appeler un script Python qui exécute les mêmes fonctionnalités d'expression régulière.