このアプリケーションデータを保持する必要がありますか？

Question

私はパストークンを完全修飾パスに変換するアプリケーション内のクラスを持っています。たとえば、"%MYAPPDATA%"のような文字列を取り、C:\Users\user.DOMAIN\AppData\Raoming\MyAppを返すことができます。

また、クラスには関数のオーバーロードがあり、文字列の代わりに列挙型を取ることができます。たとえば、列挙型はAppPaths.MyAppData、戻り値はC:\Users\user.DOMAIN\AppData\Raoming\MyAppです。

"ルックアップテーブル"をどこかに保存する必要がありますが、どのような方法や構造が最適かわかりません。データセットを使用してテーブルをディスクに書き込む必要がありますか？それとも記憶に残っているのか？

単一パスの値は、文字列と列挙型にマップできます。私はインデックスを列挙型の整数値にマップし、文字列を渡すときに配列を検索するメモリを持つことができます。

思考？

Answer 1

特に大きい場合を除き、私はメモリ内の配列と一緒に行きます。もう少し機能を追加し、さらにオーバーヘッドを増やすには、リストまたは辞書を使用できます。多くの機能（オーバヘッドが多い）では、メモリ内のデータセットを使用できます。

また、250-500を超える項目がない限り、プログラムの動作中にディスクストレージを使用することは実際には意味がありません。つまり、待ち時間（検索時間）とコーディングのオーバーヘッドはちょうどそれだけの価値はありません。

もちろん、プログラムをディスクに保存しておくこともできます（プログラムの起動時に読み込まれるなど）。しかし、OSからデータを引き出す場合には、これが必要ではないかもしれないとあなたの問題から考えます。

Answer 2

すべてのパフォーマンスに依存します。

データベーステーブルにデータを格納することができます（1つは "生"データ用、2つはキーと列挙間の関係用）。単純なSQLクエリで参照してください。ただし、基盤となるデータベースとキャッシュメカニズムによっては、これは最速の方法ではない可能性があります。

実行時に検索を高速化し、起動時に初期化するために2つのメモリ内マップ（辞書？）を使用することもできます。

Answer 3

もしそれが大きくなることが不可能であれば私はそれを記憶に残すでしょう - そうでなければ、後で使うためにデータベース/ファイルに保存します。

もちろん、使用方法によって異なります。私の知る限り、あなたはユーザー固有のデータへのパスを保存したいと思っています。データのパスを保存できるユーザークラスを持っている可能性はありますか？オブジェクトが、その後に構築されたとき、私はちょうど、アレイを構築する必要があり