Discussion :

[meldeve]

Bonjour à tous,

J'ai besoin de conseils et d'info pour le choix des armes à utiliser.

Voici le context :
J'ai 2 bases de données différentes (sur des instances différentes) en SQL Server 2016. BDD 1 est utilisé par le système 1 et BDD 2 par le système 2. (Je simplifie, ça évite d'embrouiller tout le monde )

Je dois synchroniser les données entre plusieurs tables de ces 2 bdd mais j'ai plusieurs cas différents :

- Cas 1 : La table A est utilisée dans le système 2 en lecture/écriture et en lecture par le système 1. Les tables sont identiques (même structure, même nom).

- Cas 2 : La table B est utilisée dans le système 1 en lecture/écriture et en lecture/écriture par le système 2. Les tables n'ont pas le même nom et la structure est quelque peu différente. Toutes les colonnes ne sont pas à mapper : table B de la BDD 1 possède une dizaine de colonne et son équivalent nommé table "B_Bis" de la BDD 2 n'en possède que 5. Une de ces colonnes est de type varchar(10) dans la table B et de type bit dans la table B_Bis (je connais les valeurs correspondantes pour le passage de la table B à la table B_Bis). La synchro doit être bidirectionnelle

- Cas 3 : Même chose que le cas 2 mais seulement en lecture par le système 2 donc pas de synchro bidirectionnelle.



On me propose l'utilisation de plusieurs techniques différentes (en parenthèse, les infos que j'ai pu collecter) :
- La "Réplication Transactionnelle" (nécessite un serveur dite de "Publication")
- L'utilisation directe d'Insert/Update... en T-SQL (Les données peuvent être transformées donc utilisable pour tous mes cas mais pose des problèmes en cas de connection défaillante ou de serveur indisponibles, pas d'asynchrone)
- SSIS (Les données peuvent être transformées donc utilisable pour tous mes cas, adapté aux lourdes charges)
- Service Broker (Asynchrone - utilisation d'au moins 2 queues, adapté aux lourdes charges, les données peuvent être transformées, Le message envoyés est un Xml donc facilement maléable)


Pour le Cas 1, le DBA propose d'utiliser la Réplication Transactionnelle et pour les cas 2 et 3, il propose d'utiliser "Service Broker". Il n'est pas fan d'SSIS.
On a besoin d'une solution asynchrone qui peux gérer de lourdes charges. La synchronisation sera lancée toutes les 10 minutes (grand max).


Mes questions :
- Peut-on faire de la transformation de donnée lorsqu'on utilise la "Réplication transactionnelle" ?
- Quel que soit la solution, le faite que les tables n'ai pas la même structure ni le même nom pose t-il un problème ?
- Suivant les cas, qu'utiliseriez vous ?
- Comment gérer le bidirectionnelle ?
- Comment savoir si une row est à jour ou non ?
- Dans chacun des cas, peut-on encrypter les données ?


Désolé pour le pavé. J'espère être relativement clair dans mes explications. Merci d'avance pour les réponses.

Cordialement,
Mel

[SQLpro]

Pour le Cas 1, le DBA propose d'utiliser la Réplication Transactionnelle et pour les cas 2 et 3, il propose d'utiliser "Service Broker". Il n'est pas fan d'SSIS.
On a besoin d'une solution asynchrone qui peux gérer de lourdes charges. La synchronisation sera lancée toutes les 10 minutes (grand max).

Votre DBA vous a proposé la bonne solution.

Mes questions :
- Peut-on faire de la transformation de donnée lorsqu'on utilise la "Réplication transactionnelle" ?

Non

- Quel que soit la solution, le faite que les tables n'ai pas la même structure ni le même nom pose t-il un problème ?

Oui et non

- Suivant les cas, qu'utiliseriez vous ?

Ce qui vous a été dit

- Comment gérer le bidirectionnelle ?

Il faut un tiers de réconciliation, car il y aura inévitablement des conflits et donc identifier d’où vient la ligne et en quelle version elle est

- Comment savoir si une row est à jour ou non ?

Se référer au tiers

- Dans chacun des cas, peut-on encrypter les données ?

Oui, mais ça va devenir très lourd à gérer

Désolé pour le pavé. J'espère être relativement clair dans mes explications. Merci d'avance pour les réponses.

Cordialement,
Mel

Pas de bleme

A +

[meldeve]

Bonjour,

Un grand merci SQLPro pour toutes les réponses apportées.

Hier, à la grande réunion sur le sujet (à laquelle mon équipe n'a pas été conviée), il a été décidé que ce serait... (roulement de tambour)... SSIS pour tous les cas. Mon client préfère confier cette tache à son DBA (ce qui me parait être le choix le plus logique). Mon équipe reste en "soutiens" et en "référence" vue qu'on a créé et sécurisé la BDD (en plus de l'appli).

J'aurais quand même appris des choses utiles sur ce sujet.

Bonne journée à tous et encore merci SQLPro,
Mel

[meldeve]

Si quelqu'un à un bon tuto à me conseiller pour la création de SSIS avec VS 2017 entre 2 bases de données SQL Server, je suis preneuse.