シナリオは次のとおりです。
Web アプリケーションを介してフィードとして提供している Web フィード アイテム (RSS/Atom) のヘッダーを返すストアド プロシージャを使用して、SQL Server データベースを処理しています。
このストアド プロシージャは、特定の間隔で実行されているサービス ブローカー タスクによって呼び出されたときに、基になるデータに重大な変更があったかどうかを確認する必要があります。データを取得/取得し、フォーマットして、SQL データベースに返す Web アプリケーションを呼び出します。
そこに、クライアントからの RSS フィード更新の要求に備えてヘッダーが格納されます。
現在、これを可能な限り効率的に設計しようとしていますが、まだいくつかのターニングポイントがあり、あなたの提案を聞きたいと思っています.
ストアド プロシージャでの私の暫定的なアプローチは次のようになります。
- データをメモリ内テーブルにまとめ、
- 情報によって変化する署名列を持つサブクエリを作成し、
- FOR XML AUTO を使用してそれらを XML に変換します。
- 結果を MD5 でハッシュします (結果のサイズに応じて HASHBYTES または fn_repl_hash_binary を使用)
- ハッシュが、フィード要求を待っている HTML を保存しているテーブルに保存されているものと一致するかどうかを確認します。
- ハッシュの一致が何もしない場合、それ以外の場合は更新を続行します。
最初の疑いは、基本データが変更されたかどうかを確認する最良の方法です。
XML に変換すると、データが大幅に膨張し、ハッシュが遅くなる可能性があります。また、ハッシュ以外の結果を使用していない可能性があります。チェックを実行したり、ハッシュのためにすべてのデータをまとめたりするより良い方法はありますか (csv のようなもの)?
クエリは複数のテーブルのデータをマージおよび集計しているため、テーブルのタイムスタンプに依存しない
2 番目のポイントは、再フォーマットのためにデータを webapp に提供する最良の方法は何ですか? - CLR 関数を介してデータを Web アプリケーションにプッシュして、データをフォーマットすることができます (ただし、これは同期的であり、複数のフィード アイテムの場合、持続不可能な遅延が発生します)。
また
代わりに結果セットを保存し、サービス ブローカーを介して複数の非同期呼び出しをトリガーすることもできます。Web アプリは、データを取得した高価なクエリを再度実行する代わりに、何らかの方法で保存されたデータを取得する場合があります。
フィード アイテムのカテゴリによってフォーマットが異なるため、同じテーブル フォーマットを使用することはできず、テーブルへの格納が難しくなります。
代わりに XML にシリアライズするかもしれません。
しかし、クエリを再実行する場合と比較して、これは大きな利益をもたらすでしょうか?