3

Nous avons une base de données SQL Server 2008 normalisée conçue à l'aide de tables génériques. Ainsi, au lieu d'avoir une table séparée pour chaque entité (par exemple, produits, commandes, commandes, etc.), nous avons des tables génériques (entités, instances, relations, attributs, etc.).Synchronisation 2 base de données avec différents schémas

Nous avons décidé d'avoir une base de données dénormalisée séparée pour la récupération rapide des données. Pourriez-vous m'indiquer s'il existe différentes technologies pour synchroniser ces deux bases de données, en supposant qu'elles ont des schémas différents?

Cheers, Mosh

+0

Est-ce que cela doit être en temps réel ou un processus Extract-Transform-Load de nuit? – Paolo

+0

https://www.symmetricds.org/ est open source et je crois que devrait le faire – kervin

Répondre

3

Lorsque deux bases de données ont radicalement différents schémas que vous devriez regarder les techniques de migration de données ou la réplication, pas de synchronisation. SQL Server fournit deux technologies pour cela, SSIS et la réplication, ou vous pouvez écrire votre propre script pour ce faire.

La réplication récupère les données nouvelles ou modifiées d'une base de données source et les copie dans une base de données cible. Il fournit des mécanismes pour la planification, l'empaquetage et la distribution des changements et peut gérer à la fois les mises à jour en temps réel et les mises à jour par lots. Pour fonctionner, il doit ajouter suffisamment d'informations dans les deux bases de données pour suivre les modifications et les lignes correspondantes. Dans votre cas, il serait difficile d'identifier quels «produits» ont changé, car vous auriez à identifier toutes les lignes modifiées pertinentes dans 4 tables différentes ou plus. Cela peut être fait, mais cela exigera des efforts. Dans tous les cas, vous devrez créer des vues qui correspondent au schéma cible, car la réplication n'autorise aucune transformation des données source. SSIS va extraire des données d'une source, les transformer et les pousser vers une cible. Il n'a aucun mécanisme intégré pour suivre les changements, vous devrez donc ajouter des champs à vos tables pour suivre les changements. C'est strictement un processus par lot qui peut fonctionner selon un calendrier. Le principal avantage est que vous pouvez effectuer une grande variété de transformations alors que la réplication ne permet quasiment aucune (sauf pour dessiner les données d'une vue). Vous pouvez créer des flux de données qui modifient uniquement le champ Produit concerné lorsqu'un enregistrement d'attribut lié au produit est modifié ou simplement reconstituer un enregistrement de produit entier et remplacer l'enregistrement cible.

Enfin, vous pouvez créer vos propres déclencheurs ou procédures stockées qui s'exécuteront lorsque les données seront modifiées et les copieront d'une base de données à l'autre.

Je tiens également à souligner que vous avez probablement sur-normalisé votre base de données. Dans les trois cas, vous aurez une certaine pénalité de performance lorsque vous joindrez toutes les tables pour reconstituer une entité, ce qui entraînera une plus grande quantité de verrouillage nécessaire et une utilisation inefficace des index. Vous sacrifiez les performances et l'évolutivité pour faciliter le changement. Vous devriez peut-être jeter un coup d'œil à la fonction de la colonne clairsemée de SQL Server 2008 pour prendre en charge les schémas flexibles tout en conservant les performances et l'évolutivité.

+0

Merci beaucoup pour votre longue réponse détaillée. Juste quelques réflexions: J'ai pensé à créer mes propres procédures stockées pour mettre à jour la base de données cible. Cependant, cela bloque la requête initiale (c'était pour modifier les données). Donc, en d'autres termes, l'utilisateur doit attendre que les données soient mises à jour à 2 endroits. J'en ai lu à propos de nServiceBus et je pensais pouvoir implémenter un dénormaliseur séparé que je peux appeler de manière asynchrone. De cette façon, l'utilisateur obtient une réponse rapidement sans avoir à attendre que la ou les bases de données de lecture soient mises à jour. Quelles sont vos pensées à ce sujet? – Mosh

+0

Aussi, comme pour SSIS, vous avez mentionné qu'il s'exécute selon un calendrier. Cela ne serait-il pas un problème pour moi dans ce cas? Imaginez que l'utilisateur insère un nouveau produit, mais SSIS peut s'exécuter 2 heures plus tard.En supposant que toutes les requêtes pour lire les données sont traitées par la base de données de lecture, l'utilisateur peut insérer un nouveau produit et ne pas le voir dans 2 heures! – Mosh