Vous n'êtes pas identifié(e).
Bonjour,
Je souhaite synchroniser 2 bases de données ayant le même schéma :
- une base "maître" : sur laquelle nous saisissons des données "communes"
- une base "client" : sur laquelle le client saisi ses propres données
Ces bases de données contiennent donc 2 types de tables :
- les tables "fermées" : que nous sommes les seuls à pouvoir alimenter
- les tables "ouvertes" : sur lesquelles le client peut ajouter ses propres enregistrements
La synchronisation consiste donc à mettre à jour la base "client" avec les données de la base "maître". Nous utilisons pour cela :
- une table "synchronisation" coté serveur, qui contient les champs suivants : id / id_serveur / nom_table / etat / date_maj_serveur => cette table est mise à jour via des triggers positionnés sur les tables impactées par la synchro
- une table "synchronisation" coté client, qui contient les champs suivants : id / id_serveur / id_client / nom_table / date_synchro / modif_client / etat / date_maj_serveur => cette table est mise à jour via le processus de synchronisation
- une table "synchro_entites" coté serveur, qui contient la liste des tables à synchroniser, avec l'ordre associé : id / nom_table / ordre
- une table "synchro_discriminants" coté serveur, qui contient les champs correspondant aux discriminants pour chaque table à synchroniser : id / table_id / ordre / nom_champ / type / parametre (si le champ représente un id d'une autre table)
Les discriminants sont utilisés pour vérifier si une donnée coté serveur corresponds à une donnée coté client lors de la synchronisation.
=> que pensez vous de cette architecture?
J'ai cependant du mal avec certaines des tables que nous synchronisons, et qui sont ouvertes aux clients :
- contacts : id / nom / prenom / id_typecontact / datenaissance / id_paysnaissance / id_nationalite / ...
- club : id / nom / adresse / telephone / id_pays / ville / nomcourt / ...
- competition : id / nom / id_zone / id_categorieage / nomcourt / nom5lettres / ...
en effet, dans ces cas la, les discriminants reposent sur des champs texte (nom/prénom) ou sur des infos qui ne seront pas forcément saisies par le client (datenaissance/id_nationalite)
=> comment réduire au maximum les risques de doublons? faut il imposer aux client la saisie d'informations (datenaissance/id_nationlite) dont ils ne disposeront pas forcément?
=> la solution est elle de prévoir également une interface de gestion des doublons?
Merci,
Hors ligne
Dès que vous avez une réplication de ce type: 2 serveurs qui peuvent mettre à jour les mêmes données, de façon asynchrone, il faut soit que vous trouviez une méthode rusée pour éviter que les deux serveurs ne génèrent des données en conflits (ce n'est souvent pas possible, et ça n'a pas l'air de l'être dans votre cas), soit gérer les doublons…
Par ailleurs, si vous partez dans cette direction, jetez un coup d'œil à bucardo si ce n'est pas déjà fait. Il est possible qu'il fasse ce que vous cherchez.
Marc.
Hors ligne
Je ne connaissais pas Bucardo, quelle est la différence avec Slony?
Pour en revenir à mon problème, quand tu parles de "méthode rusée" ca aurait pu consister en quoi?
On aurait pu tester la présence d'une donnée coté SERVEUR lors d'un ajout coté CLIENT, mais nous sommes incapables de faire ce test dans l'autre sens...
Du coup, nous sommes obligé de gérer des doublons. Y a t'il de bonnes pratiques ou des outils sur ce sujet?
Merci,
Hors ligne
Bucardo, la différence c'est qu'il sait faire du multi-maître.
Pour la méthode rusée, c'est plutôt générer des choses qui ne peuvent pas être en conflit au niveau applicatif sur les différents serveurs. Ça dépend bien trop de l'application pour que je puisses te donner des exemples 
Pour la gestion des doublons, je ne suis pas sûr qu'il y ait des bonnes pratiques
Il faudra définir des règles métiers, et/ou une interface de résolution des conflits.
Marc.
Hors ligne
Mais dans mon cas, je n'ai pas de multi-maître. J'ai par contre une base "maître" qui va alimenter différentes bases "clientes".
Du coup nous avons développé notre propre processus de synchronisation des données, avec un batch qui sera exécuté via une tâche planifiée coté client.
Cela nous permets justement d'affiner les règles métiers, mais je me demande si nous n'avons pas perdu de temps dans le développement, et si les perfs seront satisfaisantes.
Hors ligne
Vous êtes indirectement multi-maître, puisque vous avez plusieurs bases clientes qui modifient les mêmes données.
Pour les perfs, je ne peux pas vous dire. Essayez de faire les modifications par lot dans les bases, ça sera plus performant, d'un point de vue réseau et base de données (vous souffrirez moins des latences par exemple).
Vous n'avez probablement pas perdu votre temps, vous aurez certainement plus de souplesse avec votre solution (et plus de bugs, au début ).
Marc.
Hors ligne
