Discussion :

[apoingsfermes]

Bonjour,

Si vous voulez bien m'aider, il faudra prévoir un peu plus que quelques secondes !
Voici ma problématique :
J'ai une base de données MySQL (base 1) utilisée par un système de gestion de communications téléphoniques.
Je dois concevoir une application d'administration qui permettra de gérer toutes les fonctionnalités de ce système via une interface web, sans avoir à toucher à cette base de données.

Cette base est très bas niveau, et pour avoir une conception plus orientée client, on va créer une nouvelle base de données (base 2), en MSSQL cette fois-ci, qui sera une abstraction de la base 1 et ajoutera des informations client.

On veut que l'appli web d'administration dialogue uniquement avec cette nouvelle base. Il faut donc un sous-système qui répercute automatiquement les changements de la base 2 à la base 1, sachant que :
- la synchronisation est unilatérale : on considère que la base 1 ne change pas d'elle-même; et si elle le fait, elle ne doit pas en informer la base 2.
- les répercutions sont non triviales : un ajout de tuple dans la base 2 se traduira souvent par des requetes complexes dans plusieurs tables de la base 1.
- Cette synchronisation doit être automatique.

J'ai plusieurs idées :
- un compilateur qui recoit des messages de l'appli web à chaque changement de la base 2, les analyse et effectue les opérations adéquates sur la base 1. Beaucoup de boulot en perspective: le compilo, le protocole pour les messages.
- un simple parseur pourrait suffire ? (expressions regulères...)
- des triggers sur la base 2 ? Ca me semble très lourd de tout coder via des triggers, et ca n'offre peut-etre pas toute la puissance nécessaire (commits, logs...)

Votre avis m'intéresse bigrement !

[SQLpro]

Il serait plus inteligent de prendre un SGBDR qui intègre des mécanismes de réplication, car à vouloir prendre un SGBDR qui n'est pas capable de faire cela nativement cela va finir par vous couter très cher en terme de développement.

Un petit exemple ta problématqiue est résolue en 1/2 journée en prenant deux serveurs SQL Server de MS.
Il existe un assistant fort complet de mise en eouvre de réplication qui permet tout un tas de combinaisons possible (fusion, transactionnelle, capture instantanée, poste à poste...)

A +

[apoingsfermes]

Le problème, c'est que je ne peux pas changer la première base de données. Je peux à la limite concevoir ma deuxième base dans le même SGBDR, mais je doute que j'arriverai à imposer cette contrainte aux décideurs.

Par contre le mécanisme de réplication m'intéresse. Il me semblait que ça n'était qu'un moyen de copier automatiquement une base à differents endroits. Je me demande si ça a la puissance nécessaire pour faire toutes les traductions requises dans mon cas.

Sinon je me pose encore une question sur le SGBD pour la base à concevoir. Je me rends compte que cette base contiendra des informations clients, des ressources, des groupes. Bref, c'est du Active Directory. Et comme l'appli web pourrait évoluer vers une solution complète d'administration des clients et ressources, il me semble qu'Active Directory est à considérer.

[SQLpro]

une réplication est un mécanisme qui permet de prendre une collection d'articles (appellée publication) dans une base d'un serveur pour aller l'insérer ou le mettre à jour dans une autre base d'un autre serveur.

Un article est un ensemble de colonnes filtrées ou non. Autrement dit un article peut être :

• une colonne d'une seule ligne
• une colonne de plusieurs lignes
• plusieurs colonnes d'une ligne
• plusieurs colonnes de plusieurs lignes

les lignes pouvant être extraites d'une table, d'une requête (jointure) ou d'une vue.

certains SGBDR permettent de répliquer des procédures stockées. C'est souvent plus intelligent ! Par exemple plutôt que de répliquer la mise à jour de 300000 produits du catalogue avec une augmentation de 3% on peut répliquer l'exécution d'une procédure qui aura fait cette mise à jour.

Les mécanismes de réplication peuvent être basés sur :
- l'application des transactions (on capte en continue les transactions achevées et on les rejoue)
- un cliché (snapshot) des données concernées (on prend une photographie des données concernées à un intervalle régulier)
- le signalement d'évolution des données par des déclencheurs aidé par un versionning des lignes (on place dans les tables concernées un tag de ligne qui évolue à chaque mise à jour et une batterie de triggers pour envoyer les nouvelles valeurs à chaque mise à jour)

Afin que la chose se passe bien il y a généralement :
- un ou plusieurs serveur sources
- un serveur de distribution (centralise les données en cours d'évolution)
- un ou plusieurs serveur cible
Le serveur de distribution peut être localisé sur le serveur cible ou source dans certains cas.

La réplication se passe avec un temps de latence qui peut être quasi synchrone lorsque le mode transactionnel est choisit.

Seul le mode avec versionning des lignes permet des réplications bilatérales, aussi appelées fusions. Le gros handicap de ce mode est que des conflits de réplication peuvent survenir. Par exemple les serveur sources SrvA et SrvB modifient la même données au même moment. Quelle information doit prendre le serveur cible SrvC ? Des règles peuvent être automatisées (priorité de site, au max, au min, au plus long....). Mais il y aura toujours une forte gestion à entreprendre.

Enfin, la réplication, c'est toujours très consammateur de ressources. Plus le temps de latence est élevé, plus les ressources sont pompées.

Si je te dis tous cela c'est parce que faire une réplication sans utiliser un outil spécifique ou un SGBDR qui l'intègre c'est du suicide, compte tenu de la complexité et de la lourdeur de l'admin !

A titre d'exemple, lorsque j'intervient en assistance, conseil sur de la réplicatio SQL Server je facture entre 1 200 et 1 600 € HT (et hors frais) la journée !

A +

[apoingsfermes]

Bigre! Je te dois combien ?
J'ai farfouillé dans MSDN à propose de la réplication, et il semblerait qu'on ne puisse avoir que des clients Oracle ou DB2, à part MSSQL. Donc c'est mort...
Si j'utilise Active Directory, c'est pas mieux.
Bon, je crois que je vais implémenter mon propre système de synchronisation, même si ça a l'air assez lourd...

Merci pour ces infos

[co2]

Bon, je crois que je vais implémenter mon propre système de synchronisation, même si ça a l'air assez lourd...

Hello

Si tu veux implémenter ton propre système de synchronisation à la main je te conseille d'utiliser un ETL (http://fr.wikipedia.org/wiki/ETL) graphique afin, entre autre, de gagner en productivité, en maintenabilité.
Je travaille chez l'editeur Open Source qui dévelope Talend Open Studio. Je t'invite donc à tester cette voie !

Pour plus d'information, n'hésitez pas à consulter notre site web.

---
Cordialement,
Cédric Carbone
Directeur Technique Talend
Skype : cedriccarbone
Mail : ccarbone(a)talend.com

• Téléchargement de Talend Open Studio V1 (ETL Open Source) http://www.talend.com/downloads-talend.htm
• Outils communautaires (Forum, Bugtracker, Wiki, business case sous forme de tutoriels animés...) http://www.talend.com/communities-talend/index.htm