2011-12-24 25 views
7

私は約10,000のレコードを持っています。各レコードには2つのフィールドがあります.1つのフィールドは300文字までの文字列で、もう1つのフィールドは10進数値です。これは、製品名と各製品の価格を示す製品カタログのようなものです。どのようなコレクションを使用しますか?

私がする必要があるのは、ユーザーが任意の単語を入力し、その単語を含むすべての商品とその価格をリストボックスに表示できることです。それで全部です。

  1. このシナリオにはどのような種類のコレクションが最適ですか?
  2. 商品名や価格に基づいてソートする必要がある場合でも、選択肢は同じですか?

今はXMLファイルを使用していますが、コード内のすべての値を埋め込むことができるようにコレクションを使用すると考えました。あなたの提案をありがとう。

+0

タイトルにC#を入れないでください。それがタグのためのものです。 – Amy

+0

コレクションではない:SQLLiteを使用してデータを格納し、アクセスすることができます。 –

答えて

10

辞書は仕事をします。ただし、部分一致が速い場合(ユーザータイプの検索など)、同じアイテムを指し示す複数のキーを作成してパフォーマンスを向上させることができます。たとえば、「Apple」という単語は、「Ap」、「App」、「Appl」、および「Apple」で検索できます。

私はこのアプローチを、同様の数のレコードに対して非常に優れた結果で使用しました。私は10Kのソース項目を約50Kのユニークキーに変換しました。これらの辞書エントリのそれぞれは、その用語に対するすべての一致の参照を含むリストを指し示す。この小さなリストをより効率的に検索することができます。これにより多くのリストが作成されていますが、メモリのフットプリントはかなり妥当です。

一般的なスペルミスをリダイレクトするか、関連するアイテムをポイントする場合は、独自のキーを作成することもできます。これにより、各キーがリストを指しているため、ユニークキーの問題のほとんども排除されます。単一のアイテムは、その名前の各単語によって分類されてもよい。これは、複数の単語を含む長い製品名を使用している場合に非常に便利です。アイテムを分類する際に、名前の各単語を1つ以上のキーにマッピングすることができます。

また、10Kのアイテムの作成と分類が正しく行われていれば(数百ミリ秒が合理的です)、時間がかかるべきではないことを指摘しておきます。 ApplicationCache、または静的メンバーを使用したい場合は、結果をキャッシュすることができます。

要約すると、結果の構造体はDictionary<string, List<T>>です。文字列は短く(2〜6文字は正常に動作しますが)ユニークなキーです。各キーは、そのキーに一致するアイテムのList<T>(または他のコレクションのように傾いている場合)を指します。検索が実行されると、ユーザーが提供する用語に一致するキーが検索されます。あなたのキーの長さによっては、あなたの最大の長さにユーザーの検索を切り捨てるかもしれません。正しい子コレクションを見つけたら、そのコレクションを検索して、必要な方法を使用して完全一致または部分一致を検索します。

最後に、アイテムの追加情報を保存できるように、リスト内の各アイテムに軽量構造を作成することができます。たとえば、商品の名前、価格、部門、人気度を格納する小さなProductクラスを作成することができます。これにより、ユーザーに表示する結果を絞り込むことができます。

オールインワンで、インテリジェントで詳細なファジー検索をリアルタイムで実行できます。

上記の構造は、trieにほぼ等しい機能を提供する必要があります。

+1

+1はProductクラスを提案し、部分一致へのアプローチを示し、有益な答えを書く時間をとる – Adam

9

10Kレコードはあまりありません。

Dictionary<string,decimal>は請求書に適合します。 LINQを使用してキーまたは値で並べ替えたり、検索を行うことができます。

これは、製品名が一意であることを前提としています。

+0

私は同意しますが、すべての文字列が一意である場合にのみ機能することを指摘する価値があると思います。 – madd0

+0

@ madd0 - フェアポイント。回答が更新されました。 – Oded

+0

+1とDictionary <文字列、小数点>の使用を中止する必要があるとき、または効果が遅すぎるときの制限はありますか? –

関連する問題