Vue d’ensemble de l’intégration clR
S’applique à : 
SQL Server Azure SQL Managed Instance
Le CLR (Common Language Runtime) est le cœur de Microsoft .NET Framework et fournit l'environnement d'exécution de la totalité du code .NET Framework. Le code qui s’exécute dans le CLR est appelé code managé. Le CLR fournit divers fonctions et services requis pour l'exécution du programme, y compris la compilation juste-à-temps (JIT), l'allocation et la gestion de la mémoire, la mise en application de la cohérence des types, la gestion des exceptions, la gestion des threads et la sécurité. Pour plus d’informations, consultez le guide de développement .NET Framework.
Remarque
Pour plus d’informations sur l’utilisation du nouveau .NET avec les extensions de langage SQL Server, consultez Comment appeler le runtime .NET dans les extensions de langage SQL Server.
Avec le CLR hébergé dans SQL Server (appelé intégration CLR), vous pouvez créer des procédures stockées, des déclencheurs, des fonctions définies par l’utilisateur, des types définis par l’utilisateur et des agrégats définis par l’utilisateur dans le code managé. Étant donné que le code managé se compile en code natif avant l’exécution, vous pouvez obtenir des augmentations significatives des performances dans certains scénarios.
Sécurité d'accès du code
Dans SQL Server 2016 (13.x) et les versions antérieures, la sécurité d’accès au code (CAS) a empêché les assemblys d’effectuer certaines opérations.
CLR utilise la sécurité d’accès du code (CAS) dans le .NET Framework, qui n’est plus pris en charge comme limite de sécurité. Un assembly CLR créé avec PERMISSION_SET = SAFE peut-être être en mesure d’accéder aux ressources système externes, d’appeler du code non managé et d’acquérir des privilèges sysadmin. Dans SQL Server 2017 (14.x) et versions ultérieures, l’option, clr sp_configure strict security, améliore la sécurité des assemblys CLR. clr strict security est activée par défaut et traite les assemblys SAFE et EXTERNAL_ACCESS comme s’ils étaient marqués UNSAFE. L’option clr strict security peut être désactivée pour la compatibilité descendante, mais n’est pas recommandée.
Nous vous recommandons de signer tous les assemblys par un certificat ou une clé asymétrique, avec une connexion correspondante qui UNSAFE ASSEMBLY a reçu l’autorisation dans la master base de données. Les administrateurs SQL Server peuvent également ajouter des assemblys à une liste d’assemblys, que le moteur de base de données doit approuver. Pour plus d’informations, consultez sys.sp_add_trusted_assembly.
Avantages de l’intégration du CLR
Transact-SQL est conçu pour l’accès direct aux données et la manipulation dans la base de données. Bien que Transact-SQL excelle au niveau de l’accès aux données et de la gestion, il ne s’agit pas d’un langage de programmation à part entière. Par exemple, Transact-SQL ne prend pas en charge les tableaux, collections, boucles for-each, décalage de bits ou classes. Bien que certaines de ces constructions puissent être simulées dans Transact-SQL, le code managé a intégré la prise en charge de ces constructions. Selon le scénario, ces fonctionnalités peuvent fournir une raison attrayante d'implémenter certaines fonctionnalités de base de données en code managé.
Visual Basic et C# offrent des fonctionnalités orientées objet telles que l’encapsulation, l’héritage et le polymorphisme. Le code connexe peut désormais être aisément organisé en classes et en espaces de noms. Lorsque vous travaillez avec de grandes quantités de code serveur, ces fonctionnalités vous permettent d’organiser et de gérer plus facilement votre code.
Le code managé est mieux adapté que Transact-SQL pour les calculs et la logique d’exécution complexe, et offre une prise en charge étendue de nombreuses tâches complexes, notamment la gestion des chaînes et les expressions régulières. Avec les fonctionnalités trouvées dans la bibliothèque .NET Framework, vous avez accès à des milliers de classes et de routines prédéfinies. Ces classes sont facilement accessibles à partir de n’importe quelle procédure stockée, déclencheur ou fonction définie par l’utilisateur. La bibliothèque de classes de base (BCL) inclut des classes qui fournissent des fonctionnalités pour la manipulation de chaînes, les opérations mathématiques avancées, l’accès aux fichiers, le chiffrement, etc.
Remarque
Bien que la plupart de ces classes soient disponibles pour une utilisation à partir du code CLR dans SQL Server, celles qui ne sont pas appropriées pour l’utilisation côté serveur (par exemple, les classes de fenêtrage) ne sont pas disponibles. Pour plus d’informations, consultez Bibliothèques .NET Framework prises en charge.
L'un des avantages du code managé est la cohérence des types, ou l'assurance que le code n'accède aux types que de façon bien définie et autorisée. Avant que le code managé ne soit exécuté, le CLR vérifie que le code ne présente pas de risque. Par exemple, le code est vérifié pour s’assurer qu’aucune mémoire n’est lue qui n’a pas été écrite précédemment. Le CLR peut également vous assurer que le code ne manipule pas de mémoire non managée.
L'intégration du CLR offre la possibilité de meilleures performances. Pour plus d’informations, consultez Performances de l’architecture d’intégration clR.
Choisir entre Transact-SQL et le code managé
Lorsque vous écrivez des procédures stockées, des déclencheurs et des fonctions définies par l’utilisateur, vous devez décider s’il faut utiliser transact-SQL traditionnel ou un langage .NET Framework tel que Visual Basic ou C#. Utilisez Transact-SQL lorsque le code effectue principalement l’accès aux données avec peu ou pas de logique procédurale. Utilisez le code managé pour les fonctions gourmandes en ressources processeur et les procédures qui affichent une logique complexe, ou lorsque vous souhaitez utiliser la bibliothèque de classes de base du .NET Framework.
Choisir entre l’exécution dans le serveur et l’exécution dans le client
Un autre facteur dans votre décision concernant l’utilisation de Transact-SQL ou du code managé est l’endroit où vous souhaitez que votre code réside, l’ordinateur serveur ou l’ordinateur client. Le code Transact-SQL et le code managé peuvent être exécutés sur le serveur. Le code et les données se retrouvent ensemble, et vous permettent de tirer parti de la puissance de traitement du serveur. En revanche, vous souhaiterez peut-être éviter de placer des tâches gourmandes en processeur sur votre serveur de base de données. La plupart des ordinateurs clients sont aujourd’hui puissants et vous souhaiterez peut-être tirer parti de cette puissance de traitement en plaçant autant de code que possible sur le client. Le code managé peut s’exécuter sur un ordinateur client, tandis que Transact-SQL ne peut pas.
Choisir entre les procédures stockées étendues et le code managé
Les procédures stockées étendues peuvent être générées pour effectuer des fonctionnalités non possibles avec les procédures stockées Transact-SQL. Toutefois, les procédures stockées étendues peuvent compromettre l’intégrité du processus SQL Server, tandis que le code managé vérifié pour être sécurisé par type ne peut pas. En outre, la gestion de la mémoire, la planification des threads et des fibres, et les services de synchronisation sont plus profondément intégrés entre le code managé du CLR et sql Server. Avec l’intégration du CLR, vous disposez d’un moyen plus sécurisé que les procédures stockées étendues pour écrire les procédures stockées dont vous avez besoin pour effectuer des tâches non possibles dans Transact-SQL. Pour plus d’informations sur l’intégration clR et les procédures stockées étendues, consultez Performances de l’architecture d’intégration CLR.