> Data > CLR : un potentiel à découvrir

CLR : un potentiel à découvrir

Data - Par Matt Nunn - Publié le 24 juin 2010

Dans l’article « SQL Server : retour vers le futur » (www.itpro.fr), j’explique que les données sont au coeur de la majorité des systèmes informatiques modernes et que SQL Server 2005 va estomper les frontières traditionnelles du modèle d’applications multiniveaux. L’un des facteurs clé du changement de notre vision des niveaux d’une architecture informatique est l’inclusion du Common Language Runtime (CLR) dans SQL Server 2005.Cette fonctionnalité est l’une des plus commentées du nouveau produit et les avis positifs ou négatifs à son sujet sont très marqués, allant des utilisateurs qui souhaitent la désactiver ad vitam aeternam aux utilisateurs qui veulent l’employer à toutes les sauces. Les réactions à l’intégration du CLR dans SQL Server 2005 sont intéressantes. Alors qu’un membre de l’équipe de développement SQL Server effectuait une présentation sur l’intégration du CLR, une personne de l’assistance s’est levée et a crié « T-SQL est-il mort ? ». Cette question nous a incité à mettre en place une session spécifique intitulée « Non, T-SQL n’est pas mort ! ». A l’inverse, j’ai eu une conversation avec un programmeur ASP qui venait de découvrir l’intégration du CLR SQL Server et a déclaré d’emblée qu’il constituerait un emplacement remarquable pour stocker tous les assemblys .NET destinés à son site Web.

Lorsque vous considérez le CLR SQL Server, il est important de bien comprendre à quel moment il convient ou non de l’employer. L’article Microsoft « Using CLR Integration in SQL Server 2005 » (http://msdn.microsoft.com/sql /2005/2005articles/default.aspx?pull=/library/en-us/dnsql90/html/sqlclrguidance. asp) explique en détail dans quel cas mettre en oeuvre le CLR SQL Server. Son utilisation judicieuse peut résoudre nombre de problèmes pour lesquels votre solution actuelle consiste à employer du code de niveau intermédiaire. Intrinsèquement, vous pouvez considérer le CLR SQL Server comme un outil vous donnant la possibilité de déplacer des niveaux client ou intermédiaire vers le serveur une logique procédurale complexe, axée essentiellement sur des valeurs stockées dans la base de données. Il permet de tirer parti de milliers de fonctions et classes utiles disponibles dans l’API .NET Framework.

La possibilité d’employer du code géré standard peut, dans certains cas, faciliter considérablement la création de ces fonctions complexes, grâce en partie aux nombreuses constructions sophistiquées (telles que les tableaux et listes) fournies par les langages .NET, mais non prises en charge par T-SQL. Ces fonctions peuvent également décupler les performances car le code géré est précompilé, alors que T-SQL est un langage interprété. En fait, dans les situations requérant des calculs complexes, une logique conditionnelle, la manipulation de chaînes ou des actions similaires, le code géré peut surpasser largement T-SQL, avec moins d’allers et retours sur le réseau par rapport à un traitement des données sur les niveaux client ou intermédiaire.

Téléchargez cette ressource

10 tendances clés de l’Expérience Client (CX) 2025

Dans le contexte actuel, l'expérience client est un levier clé de réussite. Pour rester compétitives, les entreprises doivent adopter des stratégies CX audacieuses, en s'appuyant sur le cloud, le digital et l'IA. Alors quelles stratégies mettre en place pour garder une longueur d’avance ?

Data - Par Matt Nunn - Publié le 24 juin 2010