1

さまざまなテキストベースのフィールドを検索する必要があるアプリケーションがあります。このアプリケーションは、NHibernateをORMとして使用して開発されています。

memories検索キーワードがであるのに商品の説明が含まれているなど、キーワードが類似した単語と一致する場合でも関連する結果を返すことができるように、検索にポーターステミングを実装したいと思いますmemory。

誰かがそのようなタイプの検索のベストプラクティスを提案できますか？頭に浮かぶ最初のアイデアは、同じフィールドの2つのバージョンをデータベースに格納することです。次に例を示します。

Description
Description_Search

列はDescription、Webサイト管理者が入力したテキストであり、フロントエンドに表示されるテキストです。

にはDescription_Search同じテキストが含まれますが、Porter-Stemmingアルゴリズムを通過します。Description_Searchその場合、検索クエリは、ではなくフィールドに基づいて行われDescriptionます。

これは意味がありますか？ほぼ同じテキストの2つのバージョンを保存しなければならないのはスペースの無駄ですか？

また、Lucene.Netそのような場合に役立ちますか？また、フルテキストベースの検索のためにLucene.Netを統合することも検討していますが、まだ詳細には検討していません。

前もって感謝します！

4

1 に答える 1

0

これには2つのフィールドを使用する必要はありません。1つで十分です。フィールドには2つの「値」があります。1つはを使用して取得できる保存された値で、もう1つは検索に使用Document.Get(...)されるインデックス付きです。値を格納することも技術的には必要ありません。一般的な解決策は、データベースで元のコンテンツを検索するために使用されるIDを格納することです。これにより、作成者情報やドキュメントの場所など、より多くの情報を検索することもできます。

この場合、Lucene.Netが役立ちますが、インフラストラクチャを自分で作成する必要があります。アナライザーの構成（通常は構成するものは何もありません）を処理し、コンテンツにインデックスを付ける必要があります。コメントで述べたように、SQL Serverの全文検索機能を利用することもできますが、それ自体にいくつかの制限があります（影響を受けない場合があります）。

SQL ServerのFTSを使用していた大きな問題の1つは、Lucene.Netで機能します（Lucene.Netでほとんど何でもできるので、それを行うコードを記述しているため、これは実際には公平ではありません）。スウェーデン語のルールを使用して構成することができませんでしたåäö。実際の文字として扱う必要があります。アクセント感度を有効にするとこれが可能になりますが、発音区別符号が実際の文字として解析されることも意味します。つまり、ñとは異なりnます。（「ハラペーニョ」を検索して、「ハラペーニョ」に一致するものがないことを想像してみてください）。アクセント感度を無効にすると、基本的にすべての発音区別符号が削除され、に変わりåäö、aao単語は完全に異なります。

Lucene.Netで（SQL Server FTSと比較して）何かを書くと、結果の強調表示（クエリに一致するドキュメント内のどのフレーズを表示するか）、類似したドキュメントの検索、スペルチェック、カスタム結果のブースト、ファセットなどを提供できます。これにより、ユーザーの検索エクスペリエンスが向上します。

于 2012-08-22T18:44:51.223 に答える