Intégration du CLR - Vue d’ensemble

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 au sein du CLR est désigné sous le nom de 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 la documentation du Kit de développement (SDK) .NET Framework.

Avec le CLR hébergé dans Microsoft SQL Server (intégration du 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 en code managé. Comme le code managé est compilé en code natif avant l'exécution, vous pouvez obtenir une amélioration significative des performances dans certains scénarios.

Le code managé utilise la sécurité d'accès du code pour empêcher les assemblys d'effectuer certaines opérations. SQL Server utilise CAS pour vous aider à sécuriser le code managé et empêcher toute compromission du système d'exploitation ou du serveur de base de données.

Avantages de l'intégration du CLR

Transact-SQL est spécifiquement 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, les collections, les boucles for-each, le décalage de bits ou les 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é.

Microsoft Visual Basic .NET et Microsoft Visual C# offrent des fonctions 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 un code serveur volumineux, cela vous permet de l'organiser et de le gérer plus facilement.

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 proposées dans la bibliothèque .NET Framework, vous avez accès aux milliers de classes et routines prégénérées. Il est possible d'accéder simplement à celles-ci à partir d'une procédure stockée, d'un déclencheur ou d'une fonction définie par l'utilisateur. La bibliothèque des classes de base (BCL, Base Class Library) inclut les classes qui fournissent les fonctionnalités de manipulation de chaînes, d'opérations mathématiques avancées, d'accès aux fichiers, de chiffrement, etc.

Remarque

Alors que la plupart de ces classes sont disponibles pour être utilisées au sein du code CLR de SQL Server, celles qui ne sont pas adaptées à une 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, il est procédé à un contrôle du code pour s'assurer qu'aucune mémoire ne soit lue qui n'ait été préalablement écrite. Le CLR peut également aider à vérifier que le code ne manipule pas une mémoire non managée.

L'intégration du CLR offre la possibilité de meilleures performances. Pour plus d’informations, consultez Performances de l’intégration clR.

Avertissement

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 en mesure d’accéder à des ressources système externes, d’appeler du code non managé et d’acquérir des privilèges sysadmin. À compter de SQL Server 2017 (14.x), une option de sp_configure appelée clr strict security est introduite pour renforcer 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 assurer une compatibilité descendante, mais ceci n’est pas recommandé. Microsoft recommande que tous les assemblys soient signés par un certificat ou une clé asymétrique avec une connexion correspondante à laquelle a été accordée l’autorisation UNSAFE ASSEMBLY dans la base de données master. Pour plus d’informations, consultez CLR strict security.

Choix entre Transact-SQL et le code managé

Lors de l’écriture de procédures stockées, de déclencheurs et de fonctions définies par l’utilisateur, une décision que vous devez prendre consiste à utiliser transact-SQL traditionnel ou un langage .NET Framework tel que Visual Basic .NET ou Visual 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.

Choix entre exécution dans le serveur et 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 pouvez souhaiter éviter de placer les tâches intensives du processeur sur votre serveur de base de données. Aujourd'hui, la plupart des ordinateurs clients sont très puissants et il se peut que vous souhaitiez 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.

Choix entre procédures stockées étendues et 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’intégration CLR.

Voir aussi

Installation du .NET Framework
Architecture d’intégration du CLR
Accès aux données à partir d'objets de base de données CLR
Prise en main de l’intégration du CLR