4

ステージング テーブルは、rpc (Java RMI や何らかの Web サービス呼び出しなど) またはメッセージング キュー (JMS など) がより適切なソリューションである場合に使用されるアンチ パターンですか? それとも、ステージング テーブルの方が適している問題はありますか?

明確にするために：

ステージング テーブルとは、プロセスによってレコードがテーブルに追加され、2 つまたは複数のプロセスによって読み取られ、処理される場合を意味します。間隔の終了ステータス (1 日の終わり、支払い期間の終了など) を反映することを意図したテーブルについて言及しているのではありません。ほとんどの場合、ステージング テーブルのスキーマは、顧客やアカウントなどのアプリケーション データ型を厳密に模倣しています。

このアンチパターンの潜在的な原因:

1) 2 つのプロセスの所有者間のビジネス ユニット ウォールは、ステージングへの書き込みまたは読み取りを行うプロセスが変更されるのを防ぎます。

2) ステージングへの書き込みまたはステージングからの読み取りプロセスの信頼性が低いため、開発者は「何かが失敗した場合に」データの損失を防ぐためにテーブルを使用するようになります

3) 知識の欠如または DGAS (^%$@ を与えないでください) の態度

4

4 に答える 4

10

あなたが説明したように、ステージング テーブルは、ほとんどのデータ ウェアハウスまたは BI 環境の重要な部分です。信頼できる/回復力のあるrpcが同じ仕事をするだろうと主張することができますが、私はあなたが間違っていると思います.

データをステージング テーブルにプルすることで、本番環境からデータを移動し、さらに計算、集計、インデックスの再作成、キーの再作成などを行う可能性があります。これらの大部分は「データベース内」で達成されます。これを RPC に置き換えると、コードと CPU サイクルを DB からアプリ サーバーに移動することになり、何のメリットもありません。たとえば、アプリ サーバーはクラッシュする可能性がはるかに高く、RPC を (簡単に) ロールバックすることはできません。

もちろん、システム間でデータを確実に移動する方法はたくさんあります。ステージング テーブルはたまたま最も簡単で、最もパフォーマンスが高く、信頼性が高く、開発の観点から言えば最も安価な方法の 1 つであり、常に正しい方法であるとは限りません。いいえ。

于 2009-03-11T01:53:30.717 に答える
5

なぜそれらはアンチパターンになるのでしょうか? ステージング テーブルは、処理サービスから受信サービスを切り離すのに非常に役立ちます。このような 2 つのサービスを分離すると、すべてのメッセージがステージング テーブルに格納されるため、処理エラーやネットワーク エラーに対する回復力が大幅に向上します。

于 2009-03-11T01:54:59.763 に答える
0

私の最初の回答はイエスですが、それは主に私の状況によるものです - あなたの状況は異なるかもしれません. 比較的時間に敏感な情報をコマンド コンポーネントからレシーバー コンポーネントに送る必要があるシステムがあります。コマンド情報はデータベース テーブルに格納され、受信側は更新のためにテーブルをポーリングします。これは恐ろしい。彼らはデータベースにコマンドの記録が残るようにしましたが、実際のコマンド実行に永遠に時間がかかり、デカップリングによってレシーバーがデータベースと同期しなくなることがあります。

EMS (JMS など) が、レシーバーとデータベース インサーターの両方がリッスンするトピック、またはコマンダーからレシーバーへのキューにメッセージをブロードキャストし、レシーバーがステータス リスナーに通知してそのステータスをデータベース。

そのコードを修正するのが待ちきれません。

于 2009-03-11T01:54:46.177 に答える
0

これは、レポートの生成中にデータを保持するために非正規化されたテーブルが使用される場合のレポートの理由によるものです。その用途なら問題ないと思います。

于 2009-03-11T01:53:53.917 に答える