システムAがシステムBにデータを送信する2つのシステムがあります。各システムが互いに独立して実行でき、もう一方がダウンしてもどちらも爆発しないことが要件です。問題は、デカップリング要件を満たしながら、システムAがシステムBと通信するための最良の方法は何かということです。
システムBには現在、dbテーブルのデータをポーリングし、挿入された新しい行を処理するプロセスがあります。
提案されている設計の1つは、システムAがシステムbのdbテーブルにデータを挿入し、システムBに既存のプロセスで新しい行を処理させることです。質問は、このソリューションが2つのシステムを分離する要件を満たしているかどうかです。データベースはシステムBの一部と見なされ、システムAが使用できなくなり、システムAが爆発する可能性がありますか？
もう1つの解決策は、システムAがデータをMQキューに入れ、MQから読み取り、システムBのデータベースに挿入するプロセスを用意することです。しかし、これは単なる余分なオーバーヘッドですか？最終的に、MQキューはdbテーブルよりもフォールトトレラントですか？
一般的に言って、データベース共有は緊密な結合であり、おそらく速度の目的を除いては好ましくありません。可用性の目的だけでなく、システムAとBは将来、いくつかの時点で変更およびアップグレードされ、相互の依存関係は最小限に抑えられる必要があるためです。メッセージパッシングは明らかな依存関係ですが、共有データベースはあなたを噛む傾向があります（またはあなたの相続人）最も期待されていないときに後部に。データベース共有ルートを使用する場合は、少なくとも共有インターフェイスを専用のテーブルまたはビューで明示的にしてください。
統合には4つの一般的なレベルがあります。
これは、さまざまな状況で適用および組み合わせて、さまざまな可用性と保守性を実現できます。エンタープライズ統合パターンサイトで優れた概要を把握できます。
他の中央統合インフラストラクチャと同様に、MQは、優れた可用性、完全なフェイルオーバーなどを備えた環境でホストする必要があります。キュー調整を分散できる他のキューソリューションがあります。
通信にキューを使用します。データベースを介してシステムAからシステムBにデータを「渡す」ことはしないでください。データベースを巨大で高価な複雑なメッセージキューとして使用しています。
メッセージキューをメッセージキューとして使用します。
これは「余分な」オーバーヘッドではありません。これは、システムを分離するための最良の方法です。これはサービス指向アーキテクチャー（SOA）と呼ばれ、メッセージの使用は設計の絶対的な中心です。
MQキューは、DBテーブルよりもはるかに単純です。
RDBMSは巨大な（ほとんど想像を絶する）オーバーヘッドを使用して、トランザクションが適切に終了したことを合理的なレベルで保証するため、「フォールトトレランス」を比較しないでください。ロック。バッファリング。書き込みキュー。ストレージ管理。等等
信頼性の高いメッセージキューの実装では、バッキングストアを使用してキューの状態を維持します。オーバーヘッドは、RDBMSよりもはるかに少なくなります。パフォーマンスははるかに優れています。そして、対話するのははるかに簡単です。
SQL Serverでは、SSISパッケージまたはジョブを介してこれを実行します（レコードの数と移動するものの複雑さに応じて）。他のデータベースにもETLソリューションがあります。変更内容と処理されたエラーのログを保持できるため、ETLソリューションが気に入っています。何らかの理由で他のシステムに送信されないレコード（2つのデータベース間でデータ構造が同じになることはめったにありません）を保留に送信できます。残りのプロセスを強制終了せずにテーブルを作成します。データベースの違いを調整するためにデータが流れるときにデータを変更することもできます（ルックアップテーブルの値など、db1の完了ステータスが5でdb2の7である、またはdb2にdb1にはない必須フィールドがあると言うnullの場合は、デフォルト値をフィールドに追加する必要があります）。