アプリケーションデータの同期-レガシーと連携して新しいアプリを実行する

Question

現在、レガシーシステムを交換中です。両方のアプリケーションが並行して実行される期間があります。ユーザーはどちらのシステムでも使用できますが、データベースの同期を維持することが課題です。

新しいシステムはASP.NETで、レガシーはVB6です。両方ともSQL Serverデータベースで実行されています。現時点では、データベースが同じサーバールームにあるのか、同じ国にあるのかは不明です。

これまでの表の2つのソリューションは次のとおりです。

1. 各マシンに存在し、他のアプリケーションによって呼び出されるWebサービス。
   • ネイティブオブジェクトの基本クラスのSaveメソッドを変更する必要がありますか？これは侵襲的であり、スイッチを切る際に問題になる可能性があります。

2. 各データベースをポーリングし、変更内容を解決し、必要に応じて適応された更新を転送する単一のWindowsサービス。

   • すべてのテーブルでLastModified（DateTime）を使用できるように両方のアプリケーションのスキーマを変更して、任意の間隔で定期的なSELECTを実行できるようにする必要があります。

どちらの解決策も合理的なようです。どちらのソリューションにも長所と短所があります。ビジネスは、1つのシステムを更新してから他のシステムを表示するまでに2秒以内の遅延（！）を要求しました。それはおそらくストレッチターゲットですが、それは目指すものです。

提案されたが拒否されたその他（再検討しても構いません）は次のとおりです。

• データベーストリガー（blugrh）
• BizTalkまたはその他のバス（スレッジハンマーのようで、切り替えソリューションには複雑すぎる）
• すべてのストアドプロシージャの変更（noooo。）
• SSIS（これについてはまだ十分に知らない）

考えたことを評価してください。

編集：N.B.スキーマは完全に異なります。

Answer 1

最終的に、これはWebサービスで解決されました。本当にうまくいきました。

Answer 2

2秒、これは非常にタイトなタイムラインです。数百の変更または何かが一度にあり、ポーリング時間がほぼ必要である場合ではなく、Windowsアプリソリューションがそれをカットしないかもしれないと推測しています毎秒2以内に収まることを期待しています。

データベースは同じ構造を使用していますか？その場合、レプリケーションの実装を検討します。

編集

スキーマが完全に異なるというコメントと追加の後、2つの操作セットが実際にあると言わざるを得ません。

1. アプリのデータストレージオプションを変更して、両方のテーブルで挿入/更新/削除を行います。利点：すぐに、共有する外部プロセスがありません。欠点：すべてのコードを変更する必要がある、無効にするのが難しいなど。

2. 前述のように同期アプリケーションを作成し、変更されたデータを同期します。利点：転送が完了した後、単に無効にすることができます。欠点：特に多数のテーブルがある場合、書くのは非常に複雑です。また、それほど速くはありませんが、2秒を達成するのは非常に困難です

Answer 3

個人的には、どちらかのシステムを同時に使用するユーザーの考えを拒否します。ユーザー1がシステム1のレコード1を変更し、ユーザー2がシステム2の異なる方法でレコード1を変更した場合、どのように問題を解決しますか？

さらに、人々が新しいシステムを使用することを要求しなければ、彼らはそうしません。変更に対する抵抗は、ほとんどの組織で非常に強いです。

代わりに、何らかの理由で元に戻す必要がある場合に備えて、新しいシステムをロールアウトし、すべてを使用して、古いシステムに1時間ごとにデータを送信するように要求することをお勧めします。

2秒の同期を得るための合理的な方法はありません。それはばかげた要件であり、ビジネス側は不確実な条件でそう言われるべきではありません。

ビジネスのユーザーが不合理な何かを望んでいるときに反撃する必要がある場合があります。

Answer 4

ここで説明することは、悪夢の真っmiddle中にいるような気分にさせてくれます！移行プロセス全体で、ユーザーが2つの異なるデータベースを使用して2つの異なるアプリケーションを使用してすべてのデータを更新できるようにすることは不可能（または少なくとも非常に高価）であると考えることは不可能であることを、まずすべての人に明確にすべきだと思います！私は2秒の遅延についても話していません...

私によると、基本的な戦略は、データ更新の権限と可能性をレガシーから新しいアプリに徐々に切り替えることです。ユーザーは両側からデータを表示できますが、更新できるのはいずれかのアプリのみです。

（偶然にも、このメソッドはユーザーに新しいバージョンへの切り替えを強制し、 @ HLGEMによって既に公開されている予想される迷惑な抵抗の問題）

このルールが明確に受け入れられたら、次の手順を実行できます。

1. レガシーデータベースから新しいデータベースへのデータ転送を許可するすべての手順を設定します。今後数回はそれらを実行する必要があると思います...
2. 他の方法でデータ転送を許可するすべての手順を設定します（逆データ転送）
3. ここで、一緒に移動できるテーブルの同種のグループを識別しているはずです。これらの各グループに対して「データ転送」が得られるように、前のコードをマージします。手順と「逆転送」 1つ。

次に、これらのグループごとに

4. コードまたはデータベースレベルで更新制限を設定します
5. 「データ転送」を実行します;手順
6. 「逆送」を整理する新しいデータベースのトリガーとしてのプロシージャ

転送できる最初の種類のデータは、外部キーを含まないリストになると思います。

この方法で作業すると、現在の状況から徐々に切り替わります

• レガシーアプリの読み取り/書き込み+読み取り専用     新しいアプリ

to

• 読み取り専用のレガシーアプリ+読み取り/書き込み     新しいアプリ。