特定の問題のSQL Serverアーキテクチャ - フルテキスト検索 - フル参加の場合

Question

候補者の履歴書を検索するアプリケーションを構築中です。私は多くのレコードがあり、レジュームフィールドがかなり大きいので、アプリケーションでフルテキスト検索を使用する必要があります。問題は、高度な検索では、候補再配置設定のジップ、状態などをリストする別のテーブルRelocationItemsがあり、RelocationItemsテーブルの候補IDを介して関連しているということです。問題は、時には候補者が再配置アイテムを持たないこともあり、時には1つ持っていることもあり、時には1つ以上の再配置アイテムを持つこともあるということです。だから、十分に簡単に、完全な外部結合を使用するViewを作成し、次に候補IDにDISTINCTを使用して選択して、検索条件に基づいて特定の領域に再配置する必要がある候補を見つけ出すことができます。

このビューでは大きな問題ですが、フル・ジョインが使用されて以来、フルテキスト検索は今使用できません。 （明らかに私のフルテキストインデックスフィールドが一意ではないヌルフィールドではないため）

そして私のストアドプロシージャにはコンテナが含まれているので、コンパイルされません。

すべきこと： - ビューに基づいて新しいテーブルを作成しますか？ - 候補テーブル（おそらくXMLフィールド）に再配置項目を格納する何かを実行しますか？ （私はあなたが2008年にテーブル値のパラメータを格納することはできないと思いますか？） - Union of Tables（Queries）の何らかの並べ替えをしますか？ （候補テーブルに対して検索を実行し、再配置テーブルに対して検索を実行してから、マージまたは結合する）

この問題を回避する最善の方法をお寄せいただきありがとうございます。

Answer 1

私は完全外部結合を使用ビューを作成し、私はそれを必要とする候補者は、検索基準に基づいて、特定の地域に移転する見つける にcandidateIDにDISTINCT使用して選択することができます。

既に潜在的な問題 - 存在するサブセレクトが良いでしょう。

正しく設定されたクエリは問題ありません。結合を使用せず、副選択のために存在し、存在します。