0

データを調整する必要がある 3 つの異なるシステム (異なる会社が所有) (データの 1 つのビジネス オーナー) を統合することを考えています。オプションの 1 つは、Web サービスを使用してシステムからシステムにデータをプッシュすることです。すべてのシステムは sql サーバー上にあるため、限られたデータのレプリケーションも可能です。

両方のテクニックを試したことのある人で、長所と短所についてコメントしてください。各システムは、他のシステムにプッシュされるデータのサブセットのマスターである場合があります。具体的には、失敗したトランザクションが Web サービスでどのように処理されるのかに興味があります。

4

1 に答える 1

3

同様の環境があり、3 つのシステム (アクセス、企業所有の SQL Azure、およびサードパーティの SQL Azure) を同期させています。Web サービスの統合から始めましたが、主にパフォーマンス上の理由から、より厳密な SQL から SQL へのレプリケーションに徐々に移行しています。私たちの実装は完全にカスタムで (SQL Server が提供する組み込みの同期サービスやレプリケーション サービスを使用していません)、基本的に BulkImport とセットベースのクエリを使用して同期します。

ウェブサービス

長所

  • 疎結合 (正しく設計されている場合) であるため、一部が変更または交換された場合のリスク管理が向上します。
  • アクセス制御の向上
  • データベース上に構築された既存のアプリケーションとのより良い統合。
  • 拡張性が高い。

短所

  • 大量のデータを移動する場合、非常に遅くなる可能性があります。
  • トランザクションとデータ処理は手動で処理する必要がありますが、実行できます。

SQL 統合

長所

  • はるかに高いスループット。
  • テーブル構造のマッピングが比較的簡単であれば、管理が容易になる可能性があります。
  • トランザクション サポート。

短所

  • テーブル全体を一掃したり、列全体を台無しにしたりするなど、大きな間違いを犯しやすい.
  • セットベースのレプリケーション用に独自の統合を展開する必要がある場合、確実なエラー処理を構築するのは困難です。
  • テーブルの構造が非常に異なる場合、つまりシステムのような EAV モデルの場合、システム間の緊密な統合は非常に困難になります。

選択肢があり、パフォーマンスに問題がなければ、私は間違いなく Web サービスを選択します。私たちの 3 つのシステムの性質は、テーブル構造が大きく異なるため、バックエンド テーブル構造を単純な POCO データ構造に抽象化して渡される Web サービスは、物事をより単純に保ちます。また、3 つのシステムのうちの 1 つは、キャッシュされたレコードや同時更新などを気にせずに「機能する」Web サービスを公開する Web サイトを駆動します。

現在、Web サービス統合でトランザクション更新を処理する方法は次のようになっています (サーバーは、より複雑で失敗する可能性が高い側である必要があります)。

  1. クライアントがサーバーへの接続を開始します。
  2. クライアントがローカル トランザクションを開始します。
  3. サーバーがローカル トランザクションを開始します。
  4. サーバーはリクエストを処理します。
  5. サーバーは、成功/失敗に基づいてローカル トランザクションをコミット/ロールバックします。
  6. サーバーは、成功/失敗およびエラー メッセージを含む応答を返します。
  7. クライアントが応答を処理します。
  8. クライアントは、成功/失敗に基づいてローカル トランザクションをコミット/ロールバックします。
于 2013-02-26T22:29:10.790 に答える