辞書は仕事をします。ただし、部分一致が速い場合(ユーザータイプの検索など)、同じアイテムを指し示す複数のキーを作成してパフォーマンスを向上させることができます。たとえば、「Apple」という単語は、「Ap」、「App」、「Appl」、および「Apple」で検索できます。
私はこのアプローチを、同様の数のレコードに対して非常に優れた結果で使用しました。私は10Kのソース項目を約50Kのユニークキーに変換しました。これらの辞書エントリのそれぞれは、その用語に対するすべての一致の参照を含むリストを指し示す。この小さなリストをより効率的に検索することができます。これにより多くのリストが作成されていますが、メモリのフットプリントはかなり妥当です。
一般的なスペルミスをリダイレクトするか、関連するアイテムをポイントする場合は、独自のキーを作成することもできます。これにより、各キーがリストを指しているため、ユニークキーの問題のほとんども排除されます。単一のアイテムは、その名前の各単語によって分類されてもよい。これは、複数の単語を含む長い製品名を使用している場合に非常に便利です。アイテムを分類する際に、名前の各単語を1つ以上のキーにマッピングすることができます。
また、10Kのアイテムの作成と分類が正しく行われていれば(数百ミリ秒が合理的です)、時間がかかるべきではないことを指摘しておきます。 Application
、Cache
、または静的メンバーを使用したい場合は、結果をキャッシュすることができます。
要約すると、結果の構造体はDictionary<string, List<T>>
です。文字列は短く(2〜6文字は正常に動作しますが)ユニークなキーです。各キーは、そのキーに一致するアイテムのList<T>
(または他のコレクションのように傾いている場合)を指します。検索が実行されると、ユーザーが提供する用語に一致するキーが検索されます。あなたのキーの長さによっては、あなたの最大の長さにユーザーの検索を切り捨てるかもしれません。正しい子コレクションを見つけたら、そのコレクションを検索して、必要な方法を使用して完全一致または部分一致を検索します。
最後に、アイテムの追加情報を保存できるように、リスト内の各アイテムに軽量構造を作成することができます。たとえば、商品の名前、価格、部門、人気度を格納する小さなProductクラスを作成することができます。これにより、ユーザーに表示する結果を絞り込むことができます。
オールインワンで、インテリジェントで詳細なファジー検索をリアルタイムで実行できます。
上記の構造は、trieにほぼ等しい機能を提供する必要があります。
タイトルにC#を入れないでください。それがタグのためのものです。 – Amy
コレクションではない:SQLLiteを使用してデータを格納し、アクセスすることができます。 –