ほとんど変更されない「かなり大量」のデータを保存する実用的な方法は？
事前に計算されたルックアップテーブルなどについて考えます。アプリケーションで値をハードコーディングする代わりにデータベースを使用する方が意味があるのはどの時点ですか？値は変更されず、メンテナンス開発者からうまく分離されます。 100個の値、1k、10k、100k？約4万個の値を保存したいと思います。現在のところ、これは機械で生成されたswitchステートメントです（VS2010は不満です）。
編集：
誰かが興味を持っている場合は、これが私がこれに取り組んだ方法です：私のデータは2つの100k要素のfloat配列に格納できたので、それを行いました。データの生成には約20秒かかったので、それを1回行い、BinaryFormatterを使用して埋め込みリソースにシリアル化しました。データの解凍には、アプリケーションの起動時に約5ミリ秒かかり、私が置き換えていたデータベースの実装（これらのハードコードされた値は以前にそこに格納されていました）よりも約45,000倍優れています。
私の提案は、データをファイルまたはデータベーステーブルに保持することです。速度が問題にならない場合は、実行時にファイルまたはデータベース（データベースの方が良い）をクエリします。メモリに問題はないが、ある程度の速度が必要な場合は、プログラムの起動時にデータをメモリにロードします。 C＃では、配列、リスト、または（最適なオプション）ハッシュテーブルを使用して、実行時に必要なデータを返すメソッド（getDataValue（string keyToValue）など）を使用できます。
維持するのが非常に難しくなり、exeのフットプリントが大きくなるため、switchステートメントを使用しないことをお勧めします。
ハッシュテーブル例 http://support.Microsoft.com/kb/309357
個人的には、私はOkです。アプリケーションにハードコーディングされた任意の量のデータを保存するために、1つの特定のデプロイメントまたはホットフィックスでデータを微調整する必要がなくなるまでです。
ただし、C＃のswitchステートメントを使用したデータの保存とアクセスは、データストレージとデータアクセスモデルを密結合し、1つのメソッドアクセスメソッド（スイッチパラメーターによる）のみを意味するため、かなり不適切です。
私はデータをHashtableまたはディクショナリに格納し、データを取得するための個別のクラスと、ルックアップディクショナリの1回の入力を提供することを好みます。
最近、私はビジネスルールを指定するために小さなDSLを実装するのがかなり便利だとわかりました（ SiteMapの流暢なインターフェイス または 税計算機のインタビューの質問 ルール定義の「calc」メソッドを確認してください）。次に、これらのルールを照会するための個別のオブジェクトを提供します。この手法は、スイッチケースのシナリオに適しています。
このような分解の優れた利点の1つは、データを定義するXXXk行のブロブに触れることなく、データに多数のビューを実装できることです。
40k行切り替えステートメントは少し疑問です。私はまだクエリ操作を実行する必要があると思いますか？データをカプセル化してみましたか？次に、LINQを使用してコレクションに対してクエリ操作を実行し、パフォーマンスをテストします。 StopWatch のようなタイマーでユニットテストを実行して、具体的な時間を取得します。次に、あなたがそれがうまくいくかもしれないと思うなら。ユーザーにとってパフォーマンスが許容できるかどうかを確認します。
このような要件が2回ありました。アプリケーションはスタンドアロンであるように設計されており、データベースのセットアップやアクセスは必要ありません。どちらの場合も、XMLファイルを使用してデータを格納しました。 2.0フレームワークにあった最初のバージョンでは、古いスタイルのXML解析呼び出しを使用してデータを検索しました。新しいバージョンの3.5フレームワークでは、LINQ to XMLを使用して必要なものを見つけました。どちらの場合も、データへのアクセスはクラスにカプセル化されました。
ここで重要なことは、パブリックインターフェイスが実装をカプセル化することを確認することですが、それはあなたの質問ではなく、そうではないと考える理由はありません。それを超えて、それはパフォーマンスと悲しみの問題です（そしてパフォーマンスの違いは気にする価値がないかもしれません）。 VS 2010の問題の実際的な解決策として、caseステートメントを常にcaseステートメントの階層に分割することができます。たとえば、最上位レベルでは、それぞれが4000ケースのcaseステートメントを持つ他の10のメソッドの1つを呼び出すことができます。必要に応じて、10個のファイルをそれぞれ独自のファイルに入れることができます。少し醜いですが、とにかくコードを生成しています。
DBに切り替える数については、DBを使用しないことが問題になるときだけです。
SQL Compactなどを使用できます。データをテーブルに入れ、DBファイルをプロジェクトに残します。表は、switchステートメントよりもその量のデータに適しています。
ここのキーワードは「ほとんどない」と思います
データneverが変更された場合（たとえば、事前計算された数学値、色定数など）、サイズが管理可能である限り、コード内に保持してください。パフォーマンスに問題がある場合、case/switchステートメントは他のオプションに比べて非常に遅くなることに注意してください。
データ（ほとんど）が変更されない場合（たとえば、電話の市外局番、国境など）、おそらくデータを外部に保持する方法を検討するでしょう。特に、それが数十以上の値になるようになった場合。
大量のデータをアプリケーションに格納すると、プログラムの読み込みが遅くなり、誰かがバイナリや実行可能ファイルで遊んだ場合にコードが危険にさらされる可能性があります。
また、プログラムが何度も編集されている場合、ご存じのとおり、誤って数値をタイプミスしたり、変更コマンドの結果としてエラーが発生する可能性があります。
将来的には、誰かがデータに対してクエリを実行するように要求する場合があります。たとえば、誰かが列の平均を要求する場合があります。その場合、アプリケーションを変更し、ユーザーが表示するすべてのクエリを計算するメソッドを追加する必要がありますで、コードを本番環境にプロモートするためのすべてのステップに進みます。これは本当に良くありません。
特にデータが大きい場合は、データとコードを分離することをお勧めします。