Azureの検索 -

Question

は、私は複数の顧問に接続し、これらの顧問は、複数の組織

Individuals--> Advisors (m:n relationship) 
Advisors --> Enterprises (m:n relationship) 

ビジネスニーズがあるとの提携を持っている個人間の連携を描いた次のスキーマを含むデータベースを持つネストされたSQLクエリの結果を複製これらすべてのコンセプトの検索を可能にし、AdvisorIdsの周りの結果を整理します。この向けて

a) Advisor1-> connected to Individuals A,B,C; and linked to Enterprises X,Y 

b) Advisor2-> connected to Individuals A, E; and linked to Enterprises M,X,Z 

を次のように一例として、検索結果の表示が可能性があり、当社はこれらの概念とそれらの間の関係に平坦化されたテーブルを作成しました。したがって、同じAdvisorIdは、複数の行

私は文字列を検索

に表示される、私はAdvisorId周り ALLレコードは個々のレコードの検索スコアに関係なく、一緒に返されることを確実にしたいです。

一つのアプローチは、遅延につながるAzureの外で行われます。ここ

a) first run an Azure Search and get a result of AdvisorId, ordered by search score of each record. This will repeat Advisor Ids 

b) take a distinct set of AdvisorIds (across pages) via standard SQL 

c) for each AdvisorId, pick all the related records via standard SQL 

2質問

（b）と（c）の処理に多くの可能性があります。また、（a）のページネーションを使用する場合、私はAdvisorIdの数が決してわからないので、別の操作の後に終了します。

ネストされた検索を実装する方法があるかどうかを確認したいと思います単一のAPI呼び出しとして（a）、（b）、（c）を行うAzure

（a）と（b）を扱うためにファセットを使用する場合は、ファセット内の最良の検索スコアドキュメント

Answer 1

データを異なる方法でモデル化しない限り、1回のリクエストで目的を達成する方法はありません。個人アドバイザーとアドバイザーと企業の関係を非正規化する代わりに、アドバイザーごとに1つの文書を持ち、コレクションを使用して関連する個人や企業に関する情報を保管することもできます。これは、アドバイザに関連する個人および企業に対して相関フィルタリングをサポートする必要があるかどうかによって、機能する場合とできない場合があります。このアプローチがあなたのために働くかどうかを評価するのに役立つホワイトペーパーhereがあります。

別のオプションとして、個人、アドバイザ、および企業を別々のインデックスとしてモデル化し、3つのクエリを発行し、クライアント側の参加を行うこともできます。ただし、これは、個人および企業に関する照会で送信する必要があるアドバイザーIDの数によって制限されます。 Azure Searchにはlimits on the size of filtersがあり、クエリのリコールが少ない場合を除き、これを実行できません。

あなたのようなシナリオでは、Azure Searchをより良くするために取り組んでいます。たとえば、現在、complex typesのサポートを追加しています。ユーザーの声に投票し、他の機能があれば助けてください。