ストアド プロシージャを使用する必要はないと思います。コマンドは、その中に含まれる select ステートメントに直接基づくことができます。
個人的に私は SqlCacheDependency を避けています。私は常に、そのベースとなるブローカー システムが対応できない何かがクエリに含まれている可能性があることを常に懸念しており、それらが何であるかを常に覚えているとは限りません。また、ボンネットの下が少し複雑すぎるように見えるので、壊れやすい側にあるのではないかと心配しています.
編集
ユーザーがプロファイルを更新する特定のケースでは、プロファイルを更新するコードでキャッシュされたコピーを削除します。
より一般的な意味では、最新の情報を受信するための許容可能な待ち時間を確立し、絶対有効期限をそれに設定します。
コストのかかる SQL クエリの場合、一般的な集計を他のテーブルにステージングし、このデータ (SP など) を更新するコードを使用して、ステージングされたデータを調整または削除することを検討します。
SqlCacheDepencency を絶対に使用しないと言っているわけではありませんが、これまでのところ、唯一の賢明なオプションであるシナリオに遭遇したことはありませんが、それらが存在すると確信しています。データベースを変更する可能性のあるすべてのコードを完全に制御できない場合、そのようなシナリオが発生する可能性があると思います。
とにかく「最新」とは何ですか?
Web アプリケーションでは、ユーザーが表示できる可能性のある最新の情報は、最後の応答で提供された情報です。考慮すべき点がいくつかあります。
- 彼らが何かを持ってきたが、その後 5 分間電話で中断されたとします。彼らは、戻って確認するデータが 5 分前のものであり、現在は古くなっている可能性があることをどの程度認識していますか?
- ユーザーは、データが送信されるわずか数ミリ秒前に何かを取得すると、表示される内容が変更されます。これはどの程度の問題でしょうか?
- 誰かが新しいデータを入力していますが、まだ送信していません。データベース内の現在のデータ自体が古くなっていると言えますか?
私が導き出しているポイントは、システムにキャッシュの巧妙さをどれだけ取り入れても、避けられないレイテンシーがあり、あまり考えずにこの種のレイテンシーを受け入れるということです。
それを念頭に置いて、最新の情報を提供する義務があると感じる多くの状況では、そのような義務は実際には保証されていません. これの良い例は SO 自体です。ここに表示されるクエリ結果の多くは実際にはキャッシュされており、行ったことがわかっている変更と完全に一致していないデータが表示される可能性があります。しかし、他の人は私たちの変更に気づいていません。