311
9.4 À propos du code .NET
plus coûteuse qu’utile. Réservez-la à des exécutions multiples – au moins plus de trois
fois – de la même requête.
9.4 À PROPOS DU CODE .NET
Depuis SQL Server 2005, vous pouvez écrire des objets de code SQL Server dans un
langage .NET, compilé en langage intermédiaire (MSIL). Après avoir ajouté
l’assembly compilée dans les métadonnées de votre base de données (à l’aide de la
commande CREATE ASSEMBLY), vous pouvez utiliser les classes et méthodes de votre
assembly pour créer des procédures stockées, déclencheurs, fonctions utilisateur,
types de données ou fonctions d’agrégation. À la sortie de SQL Server 2005,
certaines personnes se posaient la question de passer du langage T-SQL vers .NET
pour la plupart de leurs besoins en requête, les développeurs ayant souvent une
connaissance plus poussée de C# ou VB.NET que du langage SQL. Cette question,
bien sûr, n’a pas eu de suite. Il est inutile, et d’ailleurs impossible, de vouloir
remplacer T-SQL. SQL Server est un SGBDR qui respecte autant que possible les
règles de Codd 1 , et les principes du client-serveur : les données ne sont accessibles
qu’à travers le langage de requête, ce langage étant SQL. Ainsi, même dans du code
.NET, l’accès au contenu des tables ne peut être fait qu’à travers une connexion
ouverte sur le serveur (une méthode de connexion in-process rapide est disponible,
appelée la « connexion de contexte »), et le passage de commandes T-SQL. Pour
manipuler les objets de base, le code .NET in-process dispose de... ADO.NET 2.0. Il
n’y a donc aucun moyen de remplacer la saisie de code SQL. Cette « contrainte »
« évolue » avec SQL Server 2008, dans lequel il est théoriquement possible de créer
des objets .NET qui utilisent la technologie de mapping relationnel-objet nommée
LINQ (.NET Language Integrated Query). Il devient ainsi possible de se passer de
saisir du code SQL, les bibliothèques .NET s’occupant pour vous de traduire votre
prose objet en requêtes. Il est clair que cette voie est en opposition avec le sujet de ce
livre. Si vous êtes soucieux de performances, fuyez à tout jamais cette voie.
Utilisez la technologie à bon escient. Le langage de requêtes natif de SQL Server,
Transact SQL, doit rester la solution de choix pour toute requête. Éventuellement,
comme SQL est très peu souple en ce qui concerne les traitements en boucle et
l’algorithmique, et comme le code procédural est en général plus lent en T-SQL que
dans un langage compilé, dans des cas comme la manipulation de chaînes de caractères ou des opérations mathématiques, l’intégration du CLR peut s’avouer un allié
utile. Nous parlons évidemment ici de la tentation de déplacer du code s’exécutant
1. Edgar F. Codd a publié en 1985 dans le magazine ComputerWorld deux articles restés célèbres,
qui listent treize règles, ou lois, essentielles d’un système de bases de données relationnelles. La
règle n° 12, notamment, connue sous le nom de règle de non-subversion, stipule que si le système
dispose d’un langage de bas niveau, ce langage ne peut pas contourner ou remettre en cause les
contraintes de sécurité et les règles d’intégrité énoncées au plus haut niveau. Voir http://www.sqlspot.com/Les-regles-de-CODD-pour-un-SGBD-relationnel.html.
9.4 À propos du code .NET
plus coûteuse qu’utile. Réservez-la à des exécutions multiples – au moins plus de trois
fois – de la même requête.
9.4 À PROPOS DU CODE .NET
Depuis SQL Server 2005, vous pouvez écrire des objets de code SQL Server dans un
langage .NET, compilé en langage intermédiaire (MSIL). Après avoir ajouté
l’assembly compilée dans les métadonnées de votre base de données (à l’aide de la
commande CREATE ASSEMBLY), vous pouvez utiliser les classes et méthodes de votre
assembly pour créer des procédures stockées, déclencheurs, fonctions utilisateur,
types de données ou fonctions d’agrégation. À la sortie de SQL Server 2005,
certaines personnes se posaient la question de passer du langage T-SQL vers .NET
pour la plupart de leurs besoins en requête, les développeurs ayant souvent une
connaissance plus poussée de C# ou VB.NET que du langage SQL. Cette question,
bien sûr, n’a pas eu de suite. Il est inutile, et d’ailleurs impossible, de vouloir
remplacer T-SQL. SQL Server est un SGBDR qui respecte autant que possible les
règles de Codd 1 , et les principes du client-serveur : les données ne sont accessibles
qu’à travers le langage de requête, ce langage étant SQL. Ainsi, même dans du code
.NET, l’accès au contenu des tables ne peut être fait qu’à travers une connexion
ouverte sur le serveur (une méthode de connexion in-process rapide est disponible,
appelée la « connexion de contexte »), et le passage de commandes T-SQL. Pour
manipuler les objets de base, le code .NET in-process dispose de... ADO.NET 2.0. Il
n’y a donc aucun moyen de remplacer la saisie de code SQL. Cette « contrainte »
« évolue » avec SQL Server 2008, dans lequel il est théoriquement possible de créer
des objets .NET qui utilisent la technologie de mapping relationnel-objet nommée
LINQ (.NET Language Integrated Query). Il devient ainsi possible de se passer de
saisir du code SQL, les bibliothèques .NET s’occupant pour vous de traduire votre
prose objet en requêtes. Il est clair que cette voie est en opposition avec le sujet de ce
livre. Si vous êtes soucieux de performances, fuyez à tout jamais cette voie.
Utilisez la technologie à bon escient. Le langage de requêtes natif de SQL Server,
Transact SQL, doit rester la solution de choix pour toute requête. Éventuellement,
comme SQL est très peu souple en ce qui concerne les traitements en boucle et
l’algorithmique, et comme le code procédural est en général plus lent en T-SQL que
dans un langage compilé, dans des cas comme la manipulation de chaînes de caractères ou des opérations mathématiques, l’intégration du CLR peut s’avouer un allié
utile. Nous parlons évidemment ici de la tentation de déplacer du code s’exécutant
1. Edgar F. Codd a publié en 1985 dans le magazine ComputerWorld deux articles restés célèbres,
qui listent treize règles, ou lois, essentielles d’un système de bases de données relationnelles. La
règle n° 12, notamment, connue sous le nom de règle de non-subversion, stipule que si le système
dispose d’un langage de bas niveau, ce langage ne peut pas contourner ou remettre en cause les
contraintes de sécurité et les règles d’intégrité énoncées au plus haut niveau. Voir http://www.sqlspot.com/Les-regles-de-CODD-pour-un-SGBD-relationnel.html.