Discussion :

[Paul TOTH]

Bonjour,

j'ai actuellement un système de réplication maison qui utilise des Triggers de ce type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
SET TERM ^ ;
ALTER TRIGGER REP_AGENDA ACTIVE
AFTER INSERT OR UPDATE OR DELETE POSITION 0
AS
DECLARE VARIABLE OP_VAL CHAR(1);
DECLARE VARIABLE KEY_VAL VARCHAR(100);
BEGIN
 IF (USER = 'REPL_V2') THEN EXIT;
 IF (DELETING) THEN
 BEGIN
  OP_VAL = 'D';
  KEY_VAL = OLD.AGENDA_ID;
 END
 ELSE BEGIN
  IF (UPDATING) THEN
   OP_VAL = 'U';
  ELSE
   OP_VAL = 'I';
  KEY_VAL = NEW.AGENDA_ID;
 END
 INSERT INTO REP_CHANGE_V2(ID, NOMTABLE, OPERATION, PKEY, HEURE, CLIENT, SOURCE)
 SELECT GEN_ID(GEN_REP_CHANGE_V2_ID, 1), NOM_TABLE, :OP_VAL, :KEY_VAL, 'NOW', CLIENT, USER
 FROM REP_TABLE_V2 WHERE NOM_TABLE = 'AGENDA' AND CLIENT <> USER;
 POST_EVENT 'MAJTABLE#REP_CHANGE_V2';
END
^
SET TERM ; ^

la table REP_TABLE_V2 contient la liste des tables observées par un CLIENT donné
la table REP_CHANGE_V2 est alimentée par le nom de la table, sa clé pour chaque opération (Insert Update Delete)

ça marche bien tant que la réplication se fait au fil de l'eau, mais si le PC du "CLIENT" reste éteint 15 jours, ça prend des plombes à synchroniser

je pensais ajouter quelque chose comme ça, pour limiter le nombre de lignes dans la table

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
SET TERM ^ ;
ALTER TRIGGER REP_AGENDA ACTIVE
AFTER INSERT OR UPDATE OR DELETE POSITION 0
AS
DECLARE VARIABLE OP_VAL CHAR(1);
DECLARE VARIABLE KEY_VAL VARCHAR(100);
BEGIN
 IF (USER = 'REPL_V2') THEN EXIT;
 IF (DELETING) THEN
 BEGIN
  OP_VAL = 'D';
  KEY_VAL = OLD.AGENDA_ID;
 END
 ELSE BEGIN
  IF (UPDATING) THEN
   OP_VAL = 'U';
  ELSE
   OP_VAL = 'I';
  KEY_VAL = NEW.AGENDA_ID;
 END
 
 DELETE FROM REP_CHANGE_V2 WHERE NOMTABLE = 'AGENDA' AND PKEY = :KEY_VAL;
 
 INSERT INTO REP_CHANGE_V2(ID, NOMTABLE, OPERATION, PKEY, HEURE, CLIENT, SOURCE)
 SELECT GEN_ID(GEN_REP_CHANGE_V2_ID, 1), NOM_TABLE, :OP_VAL, :KEY_VAL, 'NOW', CLIENT, USER
 FROM REP_TABLE_V2 WHERE NOM_TABLE = 'AGENDA' AND CLIENT <> USER;
 POST_EVENT 'MAJTABLE#REP_CHANGE_V2';
END
^
SET TERM ; ^

cela me permettrait de ne conserver que la dernière opération...U ou D, mon application de réplication gère le cas U sans I, et D sur un enregistrement inexistant...donc ça pourrait être suffisant je pense.

mais est-ce que je peux tomber sur une erreur de dead lock transaction qui ferait que je raterais une mise à jour ?

à moins de faire le DELETE en dernier lieu ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
SET TERM ^ ;
ALTER TRIGGER REP_AGENDA ACTIVE
AFTER INSERT OR UPDATE OR DELETE POSITION 0
AS
DECLARE VARIABLE OP_VAL CHAR(1);
DECLARE VARIABLE KEY_VAL VARCHAR(100);
BEGIN
 IF (USER = 'REPL_V2') THEN EXIT;
 IF (DELETING) THEN
 BEGIN
  OP_VAL = 'D';
  KEY_VAL = OLD.AGENDA_ID;
 END
 ELSE BEGIN
  IF (UPDATING) THEN
   OP_VAL = 'U';
  ELSE
   OP_VAL = 'I';
  KEY_VAL = NEW.AGENDA_ID;
 END
 
 ID = GEN_ID(GEN_REP_CHANGE_V2_ID, 1)
 
 INSERT INTO REP_CHANGE_V2(ID, NOMTABLE, OPERATION, PKEY, HEURE, CLIENT, SOURCE)
 SELECT :ID, NOM_TABLE, :OP_VAL, :KEY_VAL, 'NOW', CLIENT, USER
 FROM REP_TABLE_V2 WHERE NOM_TABLE = 'AGENDA' AND CLIENT <> USER;
 POST_EVENT 'MAJTABLE#REP_CHANGE_V2';
 
 DELETE FROM REP_CHANGE_V2 WHERE NOMTABLE = 'AGENDA' AND PKEY = :KEY_VAL AND ID <> :ID;
 
END
^
SET TERM ; ^

connaissez vous une autre astuce pour synchroniser plusieurs bases en bidirectionnel...en effet le principal problème que je rencontre c'est que j'ai plusieurs sites à synchroniser et chaque site peut faire des mises à jour

[SQLpro]

Les systèmes de réplications entre bases de données sont très complexes à coder et à exploiter. En particulier si la mise à jour est permise pour toutes les bases et que chacune doit être complétées par les données des autres.
En effet dans ce cas, l'effort de consolidation est exponentiel !

Prenons le cas de 2 bases ayant 1 seule table de 100 lignes. Il faut vérifier si les 100 x 100 lignes correspondent ou non, et suivant la correspondance ou non, faire des UPDATE, DELETE ou INSERT.
Dans ce cas il faudra comparer les informations de 10 000 lignes.
Avec 3 bases ayant chacune une seule table de 100 lignes, la vérification doit donc être opérée pour 100 x 100 x 100 = 1 000 000...

Vous commencez à comprendre la chose !

Certains SGBDR ont des fonctionnalités de réplication intégrées. C'est le cas de MS SQL Server qui possède 9 mécanismes différents de réplication (SNAPSHOT, TRANSACTIONNEL, PEER TO PEER, FUSION, Service Broker, Replication Oracle, Log Shippping, AlwaysOn, Mictrosoft Sync Framework...) en sus de la possibilité d'utiliser des déclencheurs

Dans le cas qui vous concerne, il faut utiliser la réplication de FUSION, et dans certains cas, un raffinement appelé réplication transactionnelle d'égal à égal (PEER TO PEER) peut être mis en place...
Dans le principe de réplication de données, un journal de suivi des modifications enregistre le "delta" ce chaque base produisant des données et l'envoie a une base de données dédiée centralisée dans laquelle chaque base cliente rapatrie les modifications qui la concerne et les applique localement. Si les bases ne sont pas en ligne, alors des informations complémentaires permettent, pour chaque table, de savoir ce qui a bougé.
Le journal de suivi des modification est élaboré à partir de la lecture binaire du journal de transaction de chaque base de données, ceci afin d'éviter l'utilisation de déclencheurs (triggers) qui sont particulièrement contre performants, d’où les problématiques que vous avez (un trigger faisant partie de la transactions en cours - INSERT, UPDATE, DELETE... - cela allonge la durée des blocages induits par les verrous exclusifs de la transaction, qui empêche, par conséquence, d'autres utilisateurs d'accéder aux données...).

En conclusion vous avez trois choix possible :
1) continuer à développer votre propre système de réplication... Courage, quelques décennies devrait suffirent !
2) trouver un logiciel du commerce (si cela existe) qui prend en charge la réplication de fusion pour FireBird...
3) changer votre SGBD !
*

Pour une explication "vulgarisé" sur les concepts de réplication, lire :
https://docs.microsoft.com/fr-fr/sql...l-server-ver15

A +

[SergioMaster]

Bonjour,

J'avoue ne pas m'être sérieusement penché dessus (je me suis mis en mode jachère intellectuelle pré vacances), j'ai juste eu une réflexion du genre "pourquoi n'utilise t-il pas INSERT OR UPDATE ?"

2) trouver un logiciel du commerce (si cela existe) qui prend en charge la réplication de fusion pour FireBird...

de mémoire il y a FBReplicator et une simple recherche permet de trouver http://www.firebirdfaq.org/faq249/

3) changer votre SGBD !

Antienne classique de ta part

[Paul TOTH]

...
En conclusion vous avez trois choix possible :
1) continuer à développer votre propre système de réplication... Courage, quelques décennies devrait suffirent !
2) trouver un logiciel du commerce (si cela existe) qui prend en charge la réplication de fusion pour FireBird...
3) changer votre SGBD !

Bonjour et merci pour cette réponse, si je suis un développeur expérimenté je n'ai pas la prétention d'être un expert BDD

1) le problème n'est pas simple, mais il est fini et connu, je ne pense pas qu'il faille des décennies pour mettre en oeuvre techniquement ce qui existe par ailleurs...reste à savoir comment faire
2) la réplication de fusion n'est pas magique, elle a une implémentation bien définie, la refaire pour Firebird ne doit pas être un travail inaccessible
3) c'est une option, mais le choix du SGBD implique des contraintes, la réplication n'est qu'un aspect du problème et n'est pas la réponse universelle

le système que j'évoque ci-dessus est en place depuis des années et permet de fonctionner de façon satisfaisante dans de nombreux cas, mais il est y a toute une série de situations qui posent problème...cela fait quelques temps que je réfléchis à des alternatives, voici mes points de réflexion

d'abord, le contexte: on parle ici de bases de données de suivi médical, patients, traitements, rdv, etc...

1) une des bases doit être la base principale, elle est accessible (à minima via un WebService) par tout le monde
2) la réplication ne doit pas se faire à travers un historique, car au quotidien , ce sont les donnés du jour qui importe, et passer 1/2h pour suivre tout l'historique alors qu'on veux la fiche patient du jour, ce n'est pas acceptable
3) la bdd (les triggers par exemple) permet de tracer les modifications afin de faciliter la synchronisation, mais la synchronisation doit se faire au niveau applicatif (càd tenir compte de la nature des informations, exemple, si je réplique un patient, les prescriptions du jour sont plus importantes que celle d'il y a 15j, et ce patient est plus important que celui qui a rdv dans 6 mois ou qui n'a aucun rdv).

du coup j'en arrive à la question, comment synchroniser deux ensembles de données (et du coup peu importe le SGBD utilisé car ce ne sera pas une réplication système) sans avoir à tout comparer.

parmi les pistes que j'ai en tête
- un champ version incrémenté à chaque mise à jour (peut-être un générateur global qui numérotera toutes les mises à jour quelque soit la table concernée)
- un uid par ligne qui identifie l'enregistrement dans la table principale (et qui n'est donc défini qu'après la première synchro)
- le champ version peut se décliner en deux champs: version locale, version centrale (couplé au uuid) afin de détecter les conflits de réplication quand les deux versions ont changé depuis la dernière synchro

on pourrait par exemple avoir pour chaque ligne les champs suivants
- uuid (numéro de l'enregistrement dans la table maitre)
- uver (numéro de version trouvé lors de la dernière synchro)
- lver (numero de version locale)

ça peut être suffisant pour une synchronisation au fil de l'eau, mais si je fait une synchro non chronologique, je vais avoir un pb pour identifier les enregistrements qui ne sont pas à jour, puisque l'idée est de trouver tous les enregistrements dont le numéro de version est > au dernier numéro de version connu, mais si je ne les traitent pas dans l'ordre ça ne marche pas

après je peux aussi faire une synchronisation en temps réel, et la base locale devient une sorte de mise en cache de la base principale, à chaque accès local je compare la version distante...et en tâche de fond je fais un synchro chronologique qui sautera ceux déjà à jour....mais c'est plus compliqué quand la base secondaire est sur un serveur avec plusieurs clients...

bref, pour l'instant je cherche plus un algorithme de synchronisation qu'autre chose

[Artemus24]

Salut à tous

Le choix de faire une seule base de données centralisée est selon moi, la meilleure solution.
Sauf qu'il existe des contraintes comme les temps d'accès. Mais est-ce grave docteur ?
Si le temps d'accès est acceptable, je ne vois pas en quoi cela pose problème.
Dans ce cas, il est important de bien choisir son SGBDR !

Je me pose l'intérêt de répartir vos données sur plusieurs serveurs. Y-a-t-il une raison à cela ?
SQLPRO a bien détaillé la contrainte géométrique (ou exponentielle) si l'on vient à disposer d'une centaine de base de données à répliquer dans l'instant.

Si chaque groupe disposant de sa clientèle propre, et possède son propre SGBDR, je ne vois pas l'intérêt de faire de la réplication master/master.
Vous devriez plutôt faire de la réplication client/master.

Mal définir les besoins futurs ou encore les sous-estimer revient par la suite à rencontrer des problèmes de performances ou de volumétries.
Il est souvent trop tard pour donner une solution viable, à moins de revoir le projet de fond en comble.

Pourquoi le choix de FireBird ?

@+

[Paul TOTH]

Salut à tous

Le choix de faire une seule base de données centralisée est selon moi, la meilleure solution.
Sauf qu'il existe des contraintes comme les temps d'accès. Mais est-ce grave docteur ?
Si le temps d'accès est acceptable, je ne vois pas en quoi cela pose problème.

le temps d'accès est un point discutable, mais l'impossibilité d'accéder aux données et un vrai problème quand il s'agit de consulter le dossier médical d'un patient qui passe sur le billard

or il arrive encore aujourd'hui que la connexion Internet ne fonctionne pas et que l'accès à une base dans un Cloud soit impossible...c'est la raison principale du choix de bases locales (ou sur une réseau local) répliquées sur les autres sites quand le praticien travaille sur plusieurs sites, typiquement: clinique/cabinet/domicile. Une partie de ces accès peut se faire à distance (domicile) mais c'est parfois plus complexe et pas toujours possible de définir une base maître accessible partout.

Par ailleurs les données de santés en ligne doivent être hébergées chez un "Hébergeur de données de santés agréé", cela a un coup non négligeable qui a mis cette option de côté pendant un certain temps.

Dans ce cas, il est important de bien choisir son SGBDR !

Je me pose l'intérêt de répartir vos données sur plusieurs serveurs. Y-a-t-il une raison à cela ?

cf plus haut

SQLPRO a bien détaillé la contrainte géométrique (ou exponentielle) si l'on vient à disposer d'une centaine de base de données à répliquer dans l'instant.

Si chaque groupe disposant de sa clientèle propre, et possède son propre SGBDR, je ne vois pas l'intérêt de faire de la réplication master/master.
Vous devriez plutôt faire de la réplication client/master.

Mal définir les besoins futurs ou encore les sous-estimer revient par la suite à rencontrer des problèmes de performances ou de volumétries.
Il est souvent trop tard pour donner une solution viable, à moins de revoir le projet de fond en comble.

Pourquoi le choix de FireBird ?

@+

Firebird est un choix historique, il est discutable, mais migrer la solution vers un autre SGBDR n'est transparent et l'effort nécessaire doit se justifier.

[SQLpro]

Une remarque préalable... Vous êtes dans un domaine très sensible que je connais bien et qui est très surveillé. J'y fais souvent du conseil pour différents clients, y compris des entreprises qui ont des solutions complétement sur Internet (gestion du diabète par exemple ou encore gestion des RV médicaux...).
Dans ce domaine, non seulement il faut être hébergé par un hébergeur, mais il faut respecter le RGPD...
Et là il y a deux éléments en défaveur de FireBird :

• le chiffrage des données sensibles (cryptage)
• l'audit des requêtes des utilisateurs.

CRYPTAGE :
Firebird ne sait faire ni l'un ni l'autre correctement.
Le chiffrement n'est pas salé. Il expose donc à des attaques par analyse fréquentielle. Der plus, les clefs de chiffrement ne sont pas protégées. Elles doivent être exposées et ouvertes à un moment donné ce qui signifie qu'une intrusion peut les capter. Enfin, tous n'est pas chiffré dans Firebird. Le journal des transactions ne l'étant pas, il est facile de récupérer des données en clair en le lisant à l'aide d'un simple outil d'édition... Les performances pour chiffrer et déchiffrer peuvent vite devenir un problème, car FireBird n'implémente pas le chiffrement transparent des données (TDE : Transparent Data Encryption). TDE permettant un excellent compromis en chiffrant toute la base y compris les journaux de transactions et les tables temporaires sans affecter les performances des requêtes...

AUDIT :
Le RGPD vous oblige a informer les autorités de tutelle dès la découverte d'intrusion dans vos données. Ceci dans un délai maximal de 72h. Pour cela il faut un système de surveillance capable de tracer TOUTES LES COMMANDES de lecture comme d'écriture avec l'identité associée à ces requêtes et mettre en oeuvre un système d'analyse qui remonte les accès non désirés aux informations.
À ma connaissance rien n'existe dans ce domaine pour auditer aussi bien les lectures que les écritures de données effectuées dans une base FireBird.

Oracle ou SQL Server intègrent ce genre de mécanisme...
Pour SQL Server ces modules sont présents :

• dans toutes les éditions pour l'audit de base de données (y compris les éditions gratuites)
• dans l'éditions standard et Enterprise pour TDE

Sans coût supplémentaire contrairement à Oracle.

Voici pour ma remarque préalable.

Pour ce qui est de la réplication de données, je vous conseille de vous inspirer de MS SQL Server qui est depuis des anées au sommet de l'art sur cette fonctionnalité (largement devant Oracle ou IBM DB2) et en particulier des mécanismes de la réplication de fusion.
Une chose n'est cependant pas bien claire dans l'explication de votre système... Vous parlez de bases locales et d'une base centralisée... Les questions sont alors les suivantes :

• la base centralisée reçoit-elle toutes les données des bases locales, sans que les bases locales ne reçoivent les données des autres bases locales ?
• la base centralisées peut elle être modifié par les utilisateurs ?
• En cas de modification de la base centrale par les utilisateurs, ces modification doivent-elles en retour être renvoyé à une base locale ? Ou toutes les bases locales ?

De la réponse à ces question dépendra la topologie de la réplication et le type de réplication à mettre en œuvre...

Pour informations, les mécanismes de réplication de SQL Server utilisent la lecture du journal de transaction pour envoyer les données à répliquer aux autres bases et non des déclencheurs qui pénalisent les performances, cause de multiples verrous et génère de nombreux "deadlocks"... Ceci afin d'être asynchrone et indépendant des transactions, donc ne pas les pénaliser... Je doute que vous ayez le temps et le courage de vous attaquer à décortiquer un journal de transaction qui est binaire et complexe et dont la structure est rarement publiée in extenso... !
Bref, sans cette lecture binaire du JT pour récupérer les mises à jour, l'accroissement du nombre de base à répliquer va devenir exponentiel et terme de coût et malheureusement vous vous en apercevrez trop tard....
Pour information Fnac.com utilise des réplications croisées entre les serveurs front-end et back-end depuis plus de 20 ans. La SNCF avec le projet Nefertiti réplique les données de plusieurs milliers de bases locales (guichets) vers un serveur centralisé pour connaître en mode "fil de l'eau" la trésorerie globale. Tout ceci avec SQL Server...

A +

[SergioMaster]

Bonjour,

On peut avoir la description de la table REP_CHANGE_V2 histoire de voir si l'UPDATE OR INSERT est possible et éviterai ces Deletes

[Paul TOTH]

Une remarque préalable... Vous êtes dans un domaine très sensible que je connais bien et qui est très surveillé. J'y fais souvent du conseil pour différents clients, y compris des entreprises qui ont des solutions complétement sur Internet (gestion du diabète par exemple ou encore gestion des RV médicaux...).
Dans ce domaine, non seulement il faut être hébergé par un hébergeur, mais il faut respecter le RGPD...

très sensible oui, très surveillé c'est discutable

...
Le RGPD vous oblige a informer les autorités de tutelle dès la découverte d'intrusion dans vos données. Ceci dans un délai maximal de 72h. Pour cela il faut un système de surveillance capable de tracer TOUTES LES COMMANDES de lecture comme d'écriture avec l'identité associée à ces requêtes et mettre en oeuvre un système d'analyse qui remonte les accès non désirés aux informations.
À ma connaissance rien n'existe dans ce domaine pour auditer aussi bien les lectures que les écritures de données effectuées dans une base FireBird.
...

non, mais il existe aussi des logiciels développés sous WinDev

toutes ces contraintes sont aussi une des raisons pour lesquelles je ne souhaite pas avoir les données qui traînent sur le net, je souhaite mettre en place des WebServices HTTPS avec certificats pour le transport des données entre des serveurs dont les données ne sont pas exposées autrement.

Pour ce qui est de la réplication de données, je vous conseille de vous inspirer de MS SQL Server qui est depuis des anées au sommet de l'art sur cette fonctionnalité (largement devant Oracle ou IBM DB2) et en particulier des mécanismes de la réplication de fusion.
Une chose n'est cependant pas bien claire dans l'explication de votre système... Vous parlez de bases locales et d'une base centralisée... Les questions sont alors les suivantes :

• la base centralisée reçoit-elle toutes les données des bases locales, sans que les bases locales ne reçoivent les données des autres bases locales ?
• la base centralisées peut elle être modifié par les utilisateurs ?
• En cas de modification de la base centrale par les utilisateurs, ces modification doivent-elles en retour être renvoyé à une base locale ? Ou toutes les bases locales ?

De la réponse à ces question dépendra la topologie de la réplication et le type de réplication à mettre en œuvre...

la base centrale est celle qui permet de mettre tous les noeuds d'accords entre eux, si A fait une modif, B et C doivent la recevoir, et vice et versa. Pour les conflits de réplication je désigne une base principale qui envoi toujours ses modifs avant de recevoir celles des autres, pour les autres c'est l'inverse...ça ne règle pas le pb des conflits entre bases secondaires, mais ça fixe la règle...mais généralement les données sont en ajout, rarement en mise à jour et donc rarement en conflit.

Pour informations, les mécanismes de réplication de SQL Server utilisent la lecture du journal de transaction pour envoyer les données à répliquer aux autres bases et non des déclencheurs qui pénalisent les performances, cause de multiples verrous et génère de nombreux "deadlocks"... Ceci afin d'être asynchrone et indépendant des transactions, donc ne pas les pénaliser... Je doute que vous ayez le temps et le courage de vous attaquer à décortiquer un journal de transaction qui est binaire et complexe et dont la structure est rarement publiée in extenso... !
Bref, sans cette lecture binaire du JT pour récupérer les mises à jour, l'accroissement du nombre de base à répliquer va devenir exponentiel et terme de coût et malheureusement vous vous en apercevrez trop tard....
Pour information Fnac.com utilise des réplications croisées entre les serveurs front-end et back-end depuis plus de 20 ans. La SNCF avec le projet Nefertiti réplique les données de plusieurs milliers de bases locales (guichets) vers un serveur centralisé pour connaître en mode "fil de l'eau" la trésorerie globale. Tout ceci avec SQL Server...

oui par contre un tel système réclame une mise en ligne régulière (si ce n'est continue) de toutes les bases sous peine de prendre des plombes pour avoir les données du jour. C'est pour cela que je pense passer à un système de réplication à un plus haut niveau.

Bonjour,

On peut avoir la description de la table REP_CHANGE_V2 histoire de voir si l'UPDATE OR INSERT est possible et éviterai ces Deletes

oui c'est envisageable, la table contient un ID enregistrement, nom de la table, type d'opération (U I D), valeur de la clé principale, et date de l’événement.

la procédure est au départ inspirée de cet article

[Artemus24]

Salut à tous.

A moins de me tromper, je comprends que ce n'est pas que de la réplication que vous faites, mais aussi de l'historisation.

@+

[Paul TOTH]

Salut à tous.

A moins de me tromper, je comprends que ce n'est pas que de la réplication que vous faites, mais aussi de l'historisation.

@+

euh...c'est à dire ?

mon but, c'est que j'ai un PC à un endroit qui accède à une base donnée (locale ou sur le LAN), un (ou plusieurs) autre(s) PC à un autre endroit qui accès à une autre base de données (locale ou sur le LAN) et que les tous les PC me permettent de travailler sur les mêmes données alors qu'ils ne sont pas forcément allumé en même temps ni forcément accessibles l'un envers l'autre.

l'idée est donc d'avoir un stockage sécurisé sur le net qui serve de tampon entre les différentes bases, il reçoit les mises à jour de chacun et délivre celles-ci à tous les autres de façon asynchrone...c'est plus un système de "messages" du coup car les données n'ont pas besoin de persister sur ce stockage une fois qu'elles ont été récupérées par tous les clients.

après il y a des subtilités dans le sens ou tous les PC n'accèdent pas à toutes les informations, mais ce n'est pas un filtrage sur le patient, mais sur la nature des informations, notamment le serveur qui gère la prise de rdv n'a pas accès aux données médicales, mais connait bien toute la patientèle...ce qui peut se gérer par la liste des tables concernées par chaque réplication.

Ce système est mis en place séparément pour chaque praticien, on ne mélange pas les données des différents praticiens (sauf s'ils sont dans le même cabinet et travaillent sur la même base).

[SQLpro]

très sensible oui, très surveillé c'est discutable

La CNIL a mis des amendes record en Europe au sujet du non respect du RGPD. Au Portugal un hôpital a eut droit à 300 000 € d'amende parce que leur logiciels ne respectait pas le RGPD. Réponse de l'hôpital qui a fait marrer tout le monde... "le choix technique du logiciel ne permettait pas le mise en oeuvre du RGPD..." c'était du MySQmerde....

Au sujet de la réplication, c'est exactement ce que fait SQL Server en standard. Dès que vous mettez en œuvre la réplication, les données sont envoyées à une base système spécialement conçue par Microsoft de nom "distribution" et qui sert d'entrepôt de données pour les abonnés. Lisez les articles que je vous aient indiqué. Ils expliquent l'architecture MS et les contraintes de mise en œuvre. Si le mode fusion est à utiliser, alors un module particulier de gestion des conflits de réplication permet de :
1) définir des règles de priorité
2) gérer les éventuels conflits

Tant que vos n'aurez pas répondu de manière détaillée à mes demandes, il sera difficile de vous aiguiller !

Prenez par exemple en considérations les problématiques suivantes :
1) quid des auto incréments s'il y en a ? (pour cela MS SQL Server permet de ne pas répliquer l'autoincrément, mais de le forcer s'il vient d'un autre serveur. Mot clef "NOT FOR REPLICATION")
2) quid des GUID/UUID s'il sont auto générés... (Même remarque avec NOT FOR REPLICATION)
3) quid des contraintes par défaut lors des insertions si l'on a forcé des NULL (idem...). Exemple dateheure du jour !
4) qui des triggers... (...)
Tout cela doit être géré dynamiquement, y compris si vous faites des modifs de structures (ALTER) des tables répliquées... Et c'est bien ce que fait MS SQL Server !

A +