私はこれについて考え、たとえばユーザーがつづりの間違いを入力した場合など、データベースをあいまい検索する方法の解決策を考え出しました。この背後にあるロジックに明らかな問題はありますか?それは機能し、以前に行われたことがありますか?
検索したいテーブル:
**tblArticles**
Body - Soundex_Body - CharacterCoded_Body
したがって、物理的な表示のために未加工のテキスト本文を保存します。他の2つの列は、次の方法で事前計算される検索に使用されます。
Soundex
本文は単語に分割され、soundexバージョンに翻訳されます。 IE、結果のボディは次のようになる可能性があります:
H252 B54 C23 E33... etc
したがって、誰かが「恐竜」と入力する可能性があり、記事の本文には「恐竜」と表示され、これらは両方ともB26と評価されます。次に、検索語句のsoundex値に対してLIKEを実行します。
文字コード
文字を素数にマップする文字マッピングを考えると、IE:
h = 2
e = 3
l = 5
o = 7
p = 11
c = 13
help = 2*3*5*11 = 330
hello = 2*3*5*5*7 = 1050
hell = 2*3*5*5 = 150
hlep = 2*5*3*11 = 330
cello = 13*3*5*5*7 = 6825
ユーザーが「hello」と入力するつもりでしたが、「hlelo」などのように2つ以上の文字を入れ替えた場合、同じ数に評価されます。生の本文を単語に分割し、すべての単語を素数エンコードしてデータベースに保存すると、次のようなフィールドが得られます。
330 6825 330 1050... etc
次に、この値を検索して、タイプミスに一致させることができます。
メリット
コメントや考えは?一種の多層検索。もちろん、戻り値に重みを付けてそれをさらに改善することもできます(つまり、文字通りの本文の一致はより価値があります)が、これはスペルミスや英語を母国語としないユーザーが検索を行うための良い解決策ですか?
他にも多くの検索アルゴリズムがあります。 Smith-Waterman は人間のテキストに適したものの1つですが、 [〜#〜] blast [〜#〜] は(これまでのところ)DNA配列の検索に最適です。 hlep
の代わりにhelp
などのさまざまなスペルエラーのあるテキストが表示された場合は、 最小編集距離 を探しています。
SQL Server 2005以降のCLRでこれらの関数の多くを実装するライブラリについては、ソースフォージプロジェクト SimMetrics を参照してください。 ブログ投稿 について SimMetrics 。
http://staffwww.dcs.shef.ac.uk/people/S.Chapman/simmetrics.html
Soundexが開発されたのは、地域のスピーチのバリエーションの主な違いが母音だけにあったためです。これが母音を放棄する理由です。転置された文字への対応は得意ではありません。
Apache Solrは、同義語とスペル修正をサポートしています。
ファジー検索はNgramを使用して実装できます。
ポーター・ステマー: http://tartarus.org/~martin/PorterStemmer/
http://wordnet.princeton.edu/ などの言語データベース
...しかし、XapianやSolrなどのプロジェクトは、これの多くを処理します。
独自のWord検索用語解析/検索エンジンを構築したい場合は、生成したトークンまたは用語を、言語検索を実行するように設計された既存のデータベースに配置することをお勧めします。
ある文字列を別の文字列に変換するために必要な変更の数をチェックし、2つの文字列がどの程度一致しているかを0と1の間の数値で返すアドレスをしばらくの間使用しました。
N/North、St/Street、EastMain/MainEastなどの項目に高い値を返すため、うまくいきました。アイデアは このCodeProjectリンク から来ました。
名前、人、場所などを照合する場合、類義語リストの方がはるかに効果的です。
Soundexは、「Dick == Richard」、「Kit == Christopher」、「Ms。== Mrs。」とは一致しません。