Discussion :

[bouchb]

Bonjour,
afin de mieux comprendre ma demande je vais vous exposez mon projet et mes problématiques.
Pour commencer je suis sapeur pompier et programmeur autodidacte.

Mon projet :
je suis chargé de développer un outils dégradé de prise d'appel 18 et le suivi des interventions en cas de dysfonctionnement du programme initial.

je vais travailler en mode client serveur ( environs 15 clients max ). Dans l'idée mon projet se composera de 4 "form" principaux ( la prise d'appel, la sélection de l'engin, un synoptique des interventions en cours et un pour les engins disponible ou en interventions dans les centres. )

mes problématiques :

Je récupère dans un premier temps les états des engins et les intervention en cours avant le plantage du système initial.

mon premier test s'est orienté sur un client en vb.net et serveur avec sql server. Le problème étant un grand nombre de requête de update et insert sur le serveur et beaucoup de sélect. le second problème étant que les clients ne sont pas au courant qu'une mise a jour des tables à été faites sur le serveur.

je me tourne donc vers vous pour orienter ma réflexion et peut être des solutions, des tutos qui pourrait m'aider.

Merci d'avance.

[DotNetMatt]

Le problème étant un grand nombre de requête de update et insert sur le serveur et beaucoup de sélect.

Ca n'est absolument pas un probleme, SQL Server est concu pour gerer des charges enormes comme par exemple au NASDAQ ou ils gerent plusieurs milliards de transactions par jour. Cela n'est bien sur faisable qu'a la seule condition d'avoir une modelisation correcte, une strategie d'indexation adaptee et bien sur une architecture technique qui supporte ton scenario.

le second problème étant que les clients ne sont pas au courant qu'une mise a jour des tables à été faites sur le serveur.

Il y a des mecanismes pour gerer cela :
- Le premier, plutot archaique et crade mais qui marche, est d'utiliser un timer et d'aller voir s'il y a eu des changements a intervalles reguliers.
- Le second est d'utiliser l'objet SqlDependency. En gros tu t'abonnes a l'evenement OnChange et tu rafraichis tes donnees lorsque cet evenement est declenche. Il y a un exemple ici : Detecting Changes with SqlDependency
- Le troisieme, c'est d'utiliser SqlDependency dans un web service, puis d'abonner tes clients au web service en full duplex. Cette methode permet juste de pouvoir ajuster (scaling) ton architecture s'il y a un enorme nombre de notifications a gerer, car tu peux ajouter/supprimer des web services au besoin. Ca peut te permettre d'intercepter les notifications et de mieux repartir ton traffic.

A noter, le type SqlDependency est connu pour avoir des fuites de memoire dans certaines situations. Si tu tombes dans ce cas, tu peux considerer une alternative : SqlTableDependency.