私たちは、比較的静的なデータベーステーブル（例えば、税率）にユーザーセッションごとに何千もの呼び出しを行うASP.NET HRアプリケーションを開発しています。ユーザーはこの情報を変更することはできず、本社で行われた変更は、たかだか1日に1回しか発生しません（また、アプリケーションで直ちに更新する必要はありません）。ASP.NETでの静的データとデータベース呼び出しの使用
すべてのデータベース呼び出しの約2/3はこれらの静的テーブルです。アプリケーションの初期化中に読み込まれ、その後24時間ごとに更新される静的オブジェクトのセットに移動することを検討しています（アプリケーションが再起動しない場合その間に）。メモリ内の合計サイズは約5MBです。
私は間違いをしますか？このアプローチの落とし穴は何ですか？
Think：時期尚早最適化。いずれにしても、テーブルとしてデータを処理する必要があります。また、「珍しいデザインパターン」を残すことになります。
イベントのデフォルトのキャッシュでは、dbmsは静的データでは効率的ですが、とにかくその5Mしかありません。あなたが記述しているdbmsパーティショニングは、しばしば反パターンとして記述されます。 1つの例：複数のクライアントの複数の同一データベース。このパターンについては、ここに他の質問があります。セキュリティ上の問題があることは理解していますが、このようにすると他のセキュリティ問題が発生します。私は最近、最終的に単一のデータベースにリファクタリングされなければならない医療請求データベース（同じくより敏感な）でこの同じ概念を見た。
これを行うと、実際の問題を解決していることがわかるまで待ってから、どの程度の違いがあるかをテストすることをおすすめします。意図しない結果には多くの機会があります。
あなたが提示した情報から、このデータをキャッシュする必要があります。ほとんど変更されず、頻繁にアクセスされるようです。しかし、「静的な」オブジェクトは不適切です：キャッシュされたデータがN時間以上経過するたびにDBにアクセスするのはなぜですか？
特別な新鮮さを必要としない場合でも、Nを任意に変更することができます.DBを4回程度打っても、1回のユーザーセッションあたりの「千回」よりもはるかに良いでしょう。
DB情報にタイムスタンプまたはdatetimeが最後に更新された時刻を記憶しておくことをお勧めします。この方法では、 "私のキャッシュはまだ新鮮ですか？"というチェックは、通常は非常に軽量です。ちょうど "最新のアップデート"情報を取得し、ローカルキャッシュを再構築した最新のアップデートでチェックしてください。 HTTPのような種類の "キャッシュ戦略"以来、変更されている場合を除いて、あなたはほとんどのDBクライアント側を実装するだろう;-)。
それは、とにかく、データベースはとにかく、それだけで何のことでもあります。 – dkretz
月の位相によっていくつかの違いがあります（または、DBのキャッシュが他のクライアントなどからの圧力を受ける可能性があります）。また、DBサーバーがWebサーバーから離れている場合、データ転送とにかく待ち時間を意味する。ローカルキャッシュはあなたのコントロール下にあります。 –
静的オブジェクトのセット（つまりシングルトン）の代わりにASP.NET Cacheオブジェクトを使用することを意味しますか？実際にデータオブジェクトのキャッシュに使用したことはなく、欠点があると考えました。 –
データをキャッシュする（対毎回データベース呼び出しを行う）場合は、静的ではなくASP.NETキャッシュを使用します。 ASP.NETキャッシュは有効期限の機能を提供し、複数の同時リクエストを処理し、SQL 2005+のクエリ通知機能を使用して自動的にキャッシュを無効にすることもできます。
スタティックを使用している場合は、とにかくそれらのものを実装することになります。
これにASP.NETキャッシュを使用する場合の欠点はありません。実際には、データもキャッシュするように設計されています（SqlCacheDependencyクラスhttp://msdn.microsoft.com/en-us/library/system.web.caching.sqlcachedependency.aspxを参照）。キャッシングで
、DBMSは、とにかくそれを特にだけ5Mたくさん静的データと効率的です。
真ですが、ここでのポイントはデータベースの往復をまったく避けることです。
ASP.NETキャッシュはこのジョブに適したツールです。
私はその点を理解しています。しかし、このパターンのほとんどのアプリケーションは、（私にとってはとにかく）SQLの結合を（特にORMを使用して）リスト参照に分解することを暗示しています。 @Mathiasが指摘しているように。ここでは、デザインの選択肢の測定と比較についての議論は一件もありません。 – dkretz
ユーザーの一致するデータをどのように見つけることができるかを説明していません。キャッシュされたセット内で外部キーを見つけるのが簡単な場合は、心配する必要はありません。 何らかのフィルタリング/並べ替え/ページングまたは最悪の検索を実装すると、ある時点でSQLのquereing機能が失われる可能性があります。
ORMはしばしば独自のquereingを持ち、linqはこれを簡単にしますが、それでもSQLではありません。 （2列でグループ化しようとすると）
時には、dbに結果セットのキーのみを返し、キャッシュを使用して完全なセットを満たすことができます。
ユーザセッションごとに何千ものコールを行う必要があるのはなぜですか？ – tuinstoel
@tuinstoel - ユーザーは有料の小切手などの情報を入力しています。 1人のユーザーが1,000個の小切手をインポートすることがあり、データベースへの50,000回のコール（給与/州/地方税タイプ、検証ステップ、賃金の最小評価など）が簡単に発生する可能性があります。 –
非常に多くの呼び出し、それは非常に過剰と思われる。あなたのORMはおそらく、行に基づく方法ではなく、集合に基づいた方法で作業することを妨げます。 – tuinstoel