Créer une CLR Stored Procedure / proc sous Sql Server 2005

Publié le par Renaud Harduin

Dans le cadre de l'étude deSQL Server 2005, nous vous proposons un article sur la création de procédures stockée CLR / Managée sous SQL Server 2005. L'avantage de ce type de programmation est que nous pouvons avoir une vue objet des ressources dans SQL Server 2005. Si l'on inscrit cela dans une optique gestion de DW, on entreouvre alors quelques portes.

Notre exemple fonctionne sous SQL Express beta 2 ... donc pourra changer quelques peu fonction des release finales

Previsualiser Voire l'Article

Publicité

Publié dans SQL Server

Pour être informé des derniers articles, inscrivez vous :
Commenter cet article
T
Benouille ... pas besoin de visual studio 2005 pour gérer ton SQL Server.<br /> <br /> tu peux déployer tes assembly contenant tes types, tes stored procedures à la mimine directement sur le SQL Server (une commande mais laquelle je ne sais plus exactement) mais c'est faisable et je l'ai testé.<br /> <br /> Pour ce qui est de l'écriture de telles assembly, tu peux utiliser notepad, #develop 2 qui devrait pas tarder à pointer le bout de son nez.<br /> <br /> de plus, les fonctions qu'utilisera SQL Server en tant que stored procedure ne font que porter un attribut suplémentaire : Microsoft.SqlServer.Server.SqlProcedure()<br /> <br /> alors tu vois rien de bien méchant ;)<br />
Répondre
R
Bonjour Benouille,As tu lu l'article ???je te parle ici d'utiliser le code objet pour générer du t*sql et non pas de créer des types objets.La question est donc de rendre maintenable du code objet et de sortir le code métier la base . Le chargement de l'assembly se fait par du sql, à la ligne de commande si tu le souhaites (pas de question sur VS).Si tu es amateur, il exite de beaux plug in pour eclipse pour le C#.Sur l'aspect coût, le modèle libre est une illusion. Fondamentalement et technologiquement, les approches sont équivalentes. J'ai travaillé sur 2 projets de taille assez importante où le modèle open source montre des couts cachés en production ...Le débat n'est donc pas "monde MS vs monde libre" (ce genre de question est un gadget) mais le retour sur investissement pour une entreprise, d'un certain nombre de ressources engagées dans un projet.
Répondre
V
certes l'offre est alléchante, mais il y a un point fondamental qui me dérange:<br /> <br /> on nous parle de créer des procédures stockées ou meme mieux des types:<br /> ainsi on va créer le type adresse qui ne sera plus qu'un champs dans la base de données, manipulable comme tel mais avec la possibilité d'accéder aux sous parties de l'objet independament, comme le code postal par exemple dans une adresse.<br /> <br /> génial.<br /> <br /> on oublie de dire que c'est inaccessible depuis sql server en création/modification: la dll créée et déployée ne le sera qu'au travers de visual studio 2005.<br /> <br /> cela veut dire qu'il faut avoir sql server 2005 et visual studio 2005, cela veut dire qu'on ne peut plus gérer les procédures métier du server sans VS2005.<br /> <br /> outre le fait d'obliger l'achat d'un vs2005 pour se servir de sqlserver2005 (ou de cette fonctionalité entre autres), cela exclue de se servir de sqlsrv 2005 dans le cadre d'un site web classique: dans le modèle LAMP, MySql est de plus en plus remplacé par sql server, avec une telle mouture ou l'on doit passer par vsnet et donc windows, on voit mal l'interopérabilité.<br /> <br /> en conclusion et pour faire tres court je dirais que l'accession a des types, fonctions utilisateur et procédures stockées définies par l'utilisateur est géniale, mais le fait de ne pouvoir les gérer EN DIRECT dans sqlserver est problématique (et on ne parle pas du prix).<br /> <br /> Benouille, déçu par des possibilités prometteuses mais ultra-avilissantes.
Répondre