おいおい。あなたは全文索引付けの暗い世界に入りました...ここからの登りは大変なので、私の友人に詰め込んでください。=)
いくつかの細かい詳細を省いたので、先に進む前に、次の 2 つのことを想定しています。
履歴書テキストを含む列は varchar(max) または nvarchar(max) です
上記の列を含むテーブルに全文索引を作成しました
さて、本題に入ります。最初に言っておきますが、私は決して SQL Server のフルテキスト インデックスの専門家ではありません (本当に誰かいますか?)...私が学んだことは、苦痛な試行錯誤によって得られたものなので、これをそのまま受け入れてください。そうは言っても、あなたの状況は、私が今年初めに直面した状況と非常に似ているように聞こえます。type (これは varchar(max) に移行しました) であり、この列には「プレーン」テキストと html でラップされたテキストの両方が含まれていました。私たちが直面した課題は、エンド ユーザーがフロント エンド アプリケーションを介してこのフルテキスト インデックスに対して検索を実行したときに、プレーン テキストと html の両方でクエリがヒットすることでした。したがって、たとえば、ユーザーが「ローマン」を検索した場合、プレーン テキスト コンテンツと「Times New Roman」を参照する html タグの両方からヒットが返される可能性があります。これは望ましい動作ではありません。
悪いニュースは、私が見つけた直接的な解決策がないことです。私が認識している唯一の可能な SQL Server 側の解決策は、列のデータ型を varbinary(max) に変換し、varbinary(max) 列を型 'HTML' として指定する 'companion' 列を作成してから、 HTML 用の Microsoft iFILTER... 詳細については、こちらとこちらを参照してください。
最終的に、次の理由により、これは私たちの進むべき道ではないと判断しました。
- iFILTER/フルテキスト インデックス作成機能の実装が 100% 成功したとしても、それが必要に応じて実行されるとは確信していませんでした。
- 列を varbinary(max) に変換すると、それ自体がパフォーマンスに影響を与えました。これは、すべての読み取りと書き込みを varbinary データ型との間でオンザフライで変換する必要があるためです...アプリケーション コードとオプティマイザに複雑なレイヤーが導入されます私たちが熱心ではなかったこと。
結果をクリーンアップするのに役立ち、この特定のプロジェクトのニーズを十分に満たすアプリケーション側のロジックを実装することになりました。
あなたが試みていることを達成しようとすることを完全に思いとどまらせたくはありませんが、少なくとも目を開けて、課題を認識して取り組んでほしいと思います...うまくいけば、それがあなたの欲求不満と無駄な時間を節約するでしょう. !
コミュニティに感謝し、成功や学んだ教訓を投稿してください。これに関する十分な情報はありませんが、他の人にとって大きな助けになるでしょう.
頑張ってください!