Synchronisation des données d'application: exécution de la nouvelle application en parallèle avec l'ancien

Question

Nous sommes en train de remplacer un ancien système. Il y aura une période de temps avec les deux applications en cours d'exécution en tandem. Les utilisateurs pourront utiliser l'un ou l'autre système et le défi consiste à pouvoir synchroniser leurs bases de données.

Le nouveau système s'appelle ASP.NET et l'héritage s'appelle VB6. Les deux s'exécutent sur une base de données SQL Server. À l'heure actuelle, on ignore si les bases de données se trouveront dans la même salle de serveurs, sans parler du même pays.

Les deux solutions proposées à ce jour sont les suivantes:

1. Les services Web installés sur chaque ordinateur et appelés par l’autre application.
   • Besoin de modifier la méthode Save sur la ou les classes de base pour les objets natifs. Ceci est invasif et pourrait poser un problème pour l'éteindre.

2. Un seul service Windows qui interroge chaque base de données et en détermine les modifications, puis transmet les mises à jour adaptées, le cas échéant.

   • Besoin de changer les schémas dans les deux applications pour s'assurer qu'elles ont un LastModified (DateTime) sur toutes les tables afin que nous puissions faire un SELECT périodique à un intervalle donné.

Les deux solutions semblent raisonnables. Les deux solutions ont des avantages et des inconvénients. L’entreprise n’a pas demandé plus de deux secondes de retard (!) Entre la mise à jour d’un système et son affichage dans l’autre. C’est peut-être une cible difficile, mais c’est quelque chose à viser.

Les autres propositions suggérées mais rejetées (je suis disposé à réexaminer) sont les suivantes:

• Déclencheurs de base de données (blugrh)
• BizTalk ou autre bus (semble être une masse et est trop complexe pour une solution de basculement)
• Modification de toutes les procédures stockées (noooo.)
• SSIS (je ne sais pas encore assez à ce sujet)

Appréciez vos pensées.

EDIT: N.B. Les schémas sont complètement différents.

Answer 1

En fin de compte, cela a été résolu avec un service Web. Cela a très bien fonctionné.

Answer 2

2 secondes, la chronologie est vraiment serrée et je suppose que votre solution pour applications Windows risque de ne pas être réduite, pas s'il y a des centaines de modifications ou quoi que ce soit en même temps, et que le temps d'interrogation doit être presque chaque seconde pour espérer le faire dans les 2.

Les bases de données utilisent-elles la même structure? Si tel est le cas, je chercherais à implémenter la réplication.

Modifier

Après le commentaire et l'ajout du fait que les schémas sont complètement différents, je dois dire que je vois vraiment deux ensembles d'opérations.

1. Modifiez les options de stockage de données dans l'application pour créer des insertions / mises à jour / suppressions dans les deux tables. Avantage: immédiat, pas de processus externe à partager. Inconvénient: modifier tout le code, difficile à désactiver, etc.

2. Créez une application de synchronisation, comme vous l'avez mentionné, pour synchroniser les données modifiées. Avantage: peut simplement être désactivé après le transfert. Inconvénient: très complexe à écrire, surtout s'il y a un grand nombre de tables. En outre, moins rapide, il sera TRÈS difficile d’accomplir 2 secondes

Answer 3

Personnellement, je rejetterais l’idée que les utilisateurs utilisent l’un ou l’autre système simultanément. Comment allez-vous résoudre le problème si l'utilisateur 1 modifie l'enregistrement 1 sur le système 1 et que l'utilisateur 2 modifie l'enregistrement 1 d'une manière différente sur le système 2?

De plus, si vous n’exigez pas que les gens utilisent le nouveau système, ils ne le feront pas. La résistance au changement est très très forte dans la plupart des organisations.

Je vous suggèrerais plutôt de déployer le nouveau système et de demander à tous de l'utiliser et d'envoyer toutes les heures les données à l'ancien système au cas où vous auriez besoin de revenir pour une raison quelconque.

Je ne vois aucun moyen raisonnable d'obtenir une synchronisation de 2 secondes. C’est une exigence ridicule et les entreprises devraient le savoir en termes clairs.

Parfois, il vous suffit de vous défendre lorsque les utilisateurs de l'entreprise veulent quelque chose de déraisonnable.

Answer 4

Ce que vous décrivez ici me donne l'impression d'être au milieu d'un cauchemar! Je pense que vous devriez commencer par expliquer clairement à tout le monde qu'il est impossible (ou du moins extrêmement coûteux) de permettre aux utilisateurs de mettre à jour toutes les données via 2 applications différentes avec 2 bases de données différentes au cours du processus de transition. ! Je ne parle même pas du délai de 2 secondes ...

Selon moi, la stratégie de base devrait être de basculer progressivement les droits et les possibilités de mise à jour des données de l’ancienne application vers la nouvelle application. Les utilisateurs pourront voir les données des deux côtés, mais ne pourront les mettre à jour que via l'une des applications.

(incidemment, cette méthode forcera également les utilisateurs à passer progressivement à la nouvelle version, en évitant problème de résistance attendu et gênant déjà exposé par @HLGEM )

Une fois que cette règle est clairement acceptée, vous pouvez alors mettre en œuvre les étapes suivantes.

1. Définissez toutes les procédures permettant le transfert de données d'une base de données existante vers une nouvelle base de données. Je suppose que vous devrez les exécuter plusieurs fois au cours des prochains mois ...
2. Définissez toutes les procédures permettant le transfert de données dans l'autre sens (transfert de données inversé)
3. Vous devez avoir identifié des groupes de tables homogènes pouvant être déplacés ensemble. Fusionnez le code précédent de manière à obtenir pour chacun de ces groupes un "transfert de données". procédure et un "transfert inversé" un.

Ensuite, pour chacun de ces groupes

4. Définissez les restrictions de mise à jour via le code ou au niveau de la base de données
5. Exécutez votre "transfert de données". procédure
6. Organisez votre "transfert inversé". procédure en tant que déclencheur dans la nouvelle base de données

Je suppose que le premier type de données que vous pourrez transférer sera des listes qui ne contiennent aucune clé étrangère.

En procédant de cette façon, vous passerez progressivement d'une situation où vous avez

• lecture / écriture de l'application héritée + lecture seule     nouvelle application

à

• application héritée en lecture seule + lecture / écriture     nouvelle application.