アーキテクチャ：セットベースのデータパイプラインチャレンジ

Question

私はさまざまなソースから構造化されたXMLデータを受け取るデータベース駆動型Webアプリケーション（ASP.NET、SQL 2008）を開発中です。データはセットに似ており、しばしば「クリーンアップ」が必要なので、XMLとしてデータベースに渡され、表示用の結果セットに変換されます。

私は、生成された「きれいな」結果をキャプチャして、アーカイブデータベースに送信してディスクに保存したいと考えています。私がこれまで考えられてきた

オプションは次のとおりです。

• は、全体の「クリーン」は、オブジェクト（直列化されたXML/.NET）に設定され、アーカイブデータベース

  にこのバックを送る結果とシリアライズ
  • PRO：簡単に再現可能 - データベースがアーカイブ・マシン上で呼び出しをキャプチャし、任意の問題を識別するためにそれらを再実行/プロファイルでき
  • CON：トリッキーなことができバージョニング

• ストアテーブル内の清掃の結果、および定期的にアーカイブマシンにこのテーブルで新鮮なレコードをコピー

  • PRO：簡単なビルド - 迅速なスケジュールされたジョブ
  • CON：上の呼び出しをREPROしにくいですアーカイブマシン。他のオプションがあります

周りの入力テーブルの内容を維持する必要があるだろう、と誰もが同じような状況での経験を持っていましたか？

Answer 1

私はsuccesfulyの両方のケースを使用していますが、私が行うことはシステムによって異なります。

保存生のXML：

は、私はどちらかの非構造化データを扱うのですか、私たちはメッセージングシステムを扱っているとき、生のXMLを保存する傾向があり、私たちはメッセージを追跡します。たとえば、デプロイされたWindowsクライアントから収集したメッセージを処理するアプリケーションでは、メッセージをリレーショナル構造にダンプしてから、倉庫にロールします。私がプロジェクトを引き継いだとき、我々は再生可能性と、システムに何が入って来るのかを正確に見ることができるので、来たraw XMLを保存し始めました。リレーショナルデータ

私は、私はデータを壊すデータの任意の報告集約を行う必要があり、通常のテーブルにそれを保存しようと思っている場合。私はあなたがデータベース内のXMLデータをクエリすることができますが、私はそれを避けようとしています。再生可能性とトラブルシューティングのために元の生のメッセージを保存することがあります。

バイナリオブジェクト

私が行っている最後のものを保存すると、全体の直列化されたバイナリオブジェクトを保存しています。オブジェクトグラフが非常に複雑で、オブジェクト間の関係が重要な場合は、これが便利です。それはバージョン管理されている巨大な欠点を持っています。しかし、私は名前空間の変更、オブジェクトの階層構造の変更などでも、これを非常にうまくバージョン管理しています。もしあなたがSQLのデータにアクセスする必要があれば、これは行く方法ではありません。