Discussion :

[theMonz31]

Bonjour à tous

Je me posais la question suivante :

Avec SQL Server, on peut créer des triggers en C#... ok, cela me va comme information.

Maintenant ma question : Est-il possible avec SQLServer ou une autre base de données d'être "notifié" d'un changement ayant eu lieu dans la base sans que le code de traitement soit dans la base ?

En clair, je voudrais savoir si quelque chose se rapprochant d'un truc genre :

IConnection myDb = ...
myDb.OnCreate+=...


Evidemment, je pourrais mettre un trigger en C# dans ma base et appelé via remoting ou socket un programme.. mais je me demandais juste si il était possible d'externaliser un tel traitement...

Merci à tous

[Guulh]

Hello,

il me semble en tous cas qu'Oracle propose depuis quelques versions un système de notification. Mais je ne sais pas si les providers pour .Net la wrappent.

[Bluedeep]

Avec le SQL CLR, tu peux à peu près tout faire en baissant un peu le niveau d'autorisation d'exécution.

Notamment, le niveau "intermédiaire" te permet de faire des appel web service sortant depuis le SQL CLR. (et des appels socket sortant en général).

Donc, il t'est parfaitement possible de coupler tes triggers avec une couche de "remontée" d'évènements.

Ceci dit, AMHA, cela n'a de sens qui si tu veux monitorer une base à laquelle accède des applications sur lesquelles tu n'as pas la main.

Dans le cas contraire (maîtrise des applications qui accèdent à la base) autant mettre la DAL sur un tier séparé et remonter les événements depuis la DAL.

[theMonz31]

ce que tu veux dire avec le tier, c'est que finalement, le DAL serait une application ou un module levant lui les evenements... Ce qui voudrait dire que toutes applications voulant acceder à ma base l'utiliserait plutot que d'attaquer directos la base...

Et effectivement, dans ce cas, ce n'est pas la base SQL qui leverait l'event mais plutot le DAL qui en fonction de la méthode appellée, lèverait un event aux applications abonnées

C'est plutot interessant comme idée !!! Par contre, ca demande à faire un "petit" effort supplémentaire pour abstraire le DAL de l'application et lui rajouter de telles fonctionnalités. Ca ne me dérange pas de faire celà, mais c'est vrai que si une application avait pu directement s'abonner à des Trigger, event provenant d'une base SQL Server, ca m'aurait éviter ce développement complémentaire.

Merci

[Bluedeep]

ce que tu veux dire avec le tier, c'est que finalement, le DAL serait une application ou un module levant lui les evenements... Ce qui voudrait dire que toutes applications voulant acceder à ma base l'utiliserait plutot que d'attaquer directos la base...

Cela suppose en effet que :

- si plusieurs appli, elles utilisent une DAL unique
- dépoter la DAL sur un tier séparé.

Et effectivement, dans ce cas, ce n'est pas la base SQL qui leverait l'event mais plutot le DAL qui en fonction de la méthode appellée, lèverait un event aux applications abonnées

C'est une technique assez classique dès l'instant où les clients d'une appli doivent être notifiés en temps réel de modifications émises par un autre client (cas type : appli de planning) et ça évite les trucs plus ou moins sale du type polling toutes les x-minutes, etc ....

C'est plutot interessant comme idée !!! Par contre, ca demande à faire un "petit" effort supplémentaire pour abstraire le DAL de l'application et lui rajouter de telles fonctionnalités.

Si ton appli est faite proprement en n-layers, le passage 3-tier n'est pas un gros boulot, l'ajout des méthodes de monitoring non plus.

Si c'est conçu "quick en dirty" (style accés direct à la DB depuis le code des GUIs comme on en voit hélas pas mal d'exemples ici), c'est plus important comme modif.

Ca ne me dérange pas de faire celà, mais c'est vrai que si une application avait pu directement s'abonner à des Trigger, event provenant d'une base SQL Server, ca m'aurait éviter ce développement complémentaire.

Comme je l'ai écrit supra, c'est aussi possible, à condition de baisser un peu le niveau de sécu par défaut. Et c'est la seule solution si tu veux monitorer des modif venant d'appli que tu ne peux pas modifier.

Dans ce cas je mettrais :

- un webservice recevant les notifications de la base
- ce webservice exposerait par ailleurs un contrat duplex WCF permettant aux appli se connectant de recevoir les notifications.

C'est plus lourd que de "remoter" une DAL bien faite.

[Guulh]

Notamment, le niveau "intermédiaire" te permet de faire des appel web service sortant depuis le SQL CLR. (et des appels socket sortant en général).

J'ai déjà vu dans des projets des triggers qui faisaient des appels web services à chaque modif d'une table donnée, le tout sans désynchronisation ; assez peu étonnamment, les perfs se croutent lamentablement et les DBA pleurent

[Bluedeep]

J'ai déjà vu dans des projets des triggers qui faisaient des appels web services à chaque modif d'une table donnée, le tout sans désynchronisation ; assez peu étonnamment, les perfs se croutent lamentablement et les DBA pleurent

Ben, un appel synchro, vaut mieux l'éviter

[theMonz31]

L'application en question n'est pas encore développée.. donc, pour le basculement d'un mode à l'autre, pas de soucis de ce coté là.

Ma question, et vous y avez brillamment répondue, avait pour but de m'indiquer ce qu'il était possible de faire et quels étaient les moyens existants pour y arriver...

Et il est clair que moins je fais de code coté SQL Server mieux je me porte. Donc, je crois que je vais retenir la solution DAL et que je ferais ainsi quand j'aurais basculé sur la phase de développement de l'application.

Thanks guys