bonjour,
 
je commence un projet qui comporte 3 bases de donnees sql server 2008. le but serait de synchroniser les 3 bases de donnees a chaque fois qu'une d'entre elles est soumis a un INSERT/DELETE/UPDATE...etc. j'ai pense a la merge replication que propose sql server. donc chaque base bdd serait a la fois client et serveur pour les replications. cela posera un probleme ? avez vous une meilleure idee ? merci

Ca marche tres bien tant que chaque table a un primary key qui est identity ou un GUID.
L'idéal est de ne synchro que le strict minimum de table et pas une DB entiere.

ok merci, je vais expliquer plus precisement :
 
a l'heure actuelle, il ya un seul serveur avec la base de donnee. l'entreprise desire faire du load balancing avec la base de donnee et des scripts ruby. elle souhaite rajouter 2 nodes contenant les scripts ruby et la base de donnee dans chaque serveur. les bases de donnees (3 en tout) doivent etre synchronisees en temps reel. exemple : lorsqu'un enregistrement dans une des bases de donnees est ajoute ou modifie, il faudrait que la modification soit egalement faite presque instantanement dans les 2 autres base de donnees.
 
est ce possible et pas trop lourd de synchroniser ces 3 bdd de maniere presque instantanee ?

C'est une relation client/serveur
 
Le serveur ou la requête a été effectuer effectue a son tour sur les deux autres client. Ceci se fait dans tous les sens si c'est bien configuré.

Il n'y a pas de solution magique qui permet de synchro des DB entieres dans tout les sens, les replications Merge ne sont pas faite pour synchro des DB entieres, ca marche tres bien sous certaine conditions et sur quelques tables.
Ca a ete crée plus pour rendre une DB disponible sur different server que pour augementer les performance et faire du load balancing.
Si la DB a ete pensée dans ce but et que chaque table remplit les conditions ca ira, sinon ca va etre un cauchemard.
 
Il faut d'abord identifier ou exactement est le probleme de performance, si ca vient des scripts il faudrai plutot penser a plusieurs application servers et garder un seul db server dédié.
Si le probleme est que la db n'arrive pas a faire les insert/delete/update assez vite la replication ne fera qu'empirer le probleme, si le probleme est que la db n'arrive pas a faire des read assez vite il y a des autres solutions (Mirroring avec mirror en read only).
Si il n'y a pas de problemes de perf mais que vous cherchez plus de la haute disponibilité vous pouvez plutot regarder du coté Mirroring (moins cher) ou Clustering (plus cher).
 
En regle general c'est tres difficil de synchroniser des db en temsp réel, mais d'un autre coté un server DB dédié est tres difficil a mettre a genoux.
Meme avec un budget raisonable vous pouvez monter a plusieurs dizaine millions de record par jours.
Evidement ca demande un structure et des query adaptée, meme le plus gros server du monde aura des problemes avec une mauvaise db.

en fait, le but de ces 3 serveurs est de rendre une bdd disponible sur differents serveurs plutot que d'augmenter les performances (comme vous dites). le load balancing est en fait prevu pour les scripts ruby mais pas pour la bdd. le truc est qu'il faudrait que les 3 bdd se synchronisent en moins de 5 secondes, est-ce possible ?  
vous avez parler de mirroring, cela pourrait etre une solution. est ce que ca rentre dans les exigences : synchonisation en moins de 5s, les 3 bdd se synchronisent entre elles (une est modifiee, les autres egalement) ?

Si vous voulez vraiment synchroniser des DB comme ca il devrai y avoir moyen de faire les synchro en moins de 5 secs mais ce n'est pas du tout garantis, ici ce genre de synchro ne se fait que toutes les 5 minutes et que sur une table.
 
Je ne comprends pas pourquoi vous avez besoin de 3 servers avec la meme DB, un seul server peut tres bien servir plusieurs application server.