Utiliser Microsoft .NET sur SQL Server

servant à vérifier les données réside au niveau base de données, pour préserver l’homogénéité des données d’application. Comme .NET est un meilleur outil pour traiter la logique, par exemple pour mettre en boucle des concaténations de chaînes et des opérations arithmétiques, vous devriez utiliser .NET quand vous avez un bloc de logique qui résidera sur un serveur de base de données qui effectue le traitement (par opposition à la sauvegarde) des données.

L’utilisation limitée du CLR (Common Language Runtime) pour améliorer le traitement pourrait aller jusqu’à utiliser une procédure stockée .NET qui traite la logique de gestion, puis appelle une procédure stockée T-SQL pour sauvegarder des données (au lieu que la procédure stockée T-SQL appelle une fonction .NET). Mais, pour la plupart des applications, l’utilisation de .NET dans des fonctions peut procurer un avantage qui ne demande pas de revoir l’architecture d’une application existante. .NET a une seconde utilisation très intéressante : définir des types de données personnalisés. Par exemple, la possibilité de définir un type complexe constitué de deux ou trois valeurs de données sous-jacentes.

L’idée étant que vous pouvez prendre des éléments de données clés de votre classe de gestion et les définir comme objets en contexte dans la base de données. Vous protégez ainsi l’intégrité des données car seuls les objets valides sont sauvegardés dans la base de données.

Mais ne perdez pas de vue que, ce faisant, vous allez lier une version spécifique de la classe dans votre application à votre base de données : donc, attention à la maintenance à long terme. C’est pourquoi, au début, il vaut mieux ne créer que des types de données personnalisés simples. Enfin, sachez aussi que l’utilisation des procédures stockées .NET remplace l’usage des procédures stockées étendues (XP, extended stored procedures). Je précise que vos appels actuels adressés à COM continueront à fonctionner.

Cependant, compte tenu que les XP sont dangereux parce qu’ils peuvent accéder à des portions de l’OS serveur sans omission, il est bon d’enlever les XP de votre base de données. Le CLR SQL offre un modèle de sécurité bien plus robuste car il donne la certitude qu’un tel code ne met pas votre base de données en danger.

William Sheldon