1

レガシーシステムの置き換えを進めています。両方のアプリケーションが並行して実行される期間があります。ユーザーはどちらのシステムも使用できますが、課題はデータベースを相互に同期させることです。

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

これまでのところ、テーブルにある 2 つのソリューションは次のとおりです。

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

  2. 各データベースをポーリングし、何が変更されたかを調べ、適切な更新を転送する単一の Windows サービス。

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

どちらの解決策も妥当に思えます。どちらのソリューションにも長所と短所があります。ビジネスは、1 つのシステムを更新してから別のシステムで確認するまでの遅延を 2 秒 (!) 以内にするよう求めています。それはおそらくストレッチ ターゲットですが、目指すべきものです。

提案されたが拒否された他のもの（私は再考するつもりです）は次のとおりです。

  • データベース トリガー (blogrh)
  • BizTalk またはその他のバス (スレッジ ハンマーのように見え、スイッチオーバー ソリューションには複雑すぎる)
  • すべてのストアド プロシージャを変更する (nooooo.)
  • SSIS (これについてはまだ十分にわかっていません)

あなたが持っているかもしれないどんな考えにも感謝します。

編集: 注意: スキーマは完全に異なります。

4

4 に答える 4

1

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

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

編集

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

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

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

于 2008-11-07T16:06:54.467 に答える
0

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

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

（ちなみに、この方法では、ユーザーは徐々に新しいバージョンに切り替える必要があり、@ HLGEMによってすでに公開されている予想される厄介な抵抗の問題を回避できます）

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

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

次に、これらのグループのそれぞれについて

  1. コードまたはデータベースレベルで更新制限を設定します
  2. 「データ転送」手順を実行します
  3. 「逆転送」手順を新しいデータベースのトリガーとして整理します

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

このように作業することで、あなたはあなたが持っている状況から徐々に切り替わります

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

に

  • 読み取り専用のレガシーアプリ+読み取り/書き込みの新しいアプリ。
于 2008-11-14T10:37:23.610 に答える
0

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

于 2009-01-14T22:40:14.270 に答える
0

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

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

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

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

ビジネス ユーザーが理不尽なことを要求した場合、反撃しなければならないこともあります。

于 2008-11-07T16:46:42.720 に答える