關於視圖的設計建議

Question

我有一個視圖（ObjectFlattenedView），它將來自各種表和視圖的數據點展平，其中包含與感興趣的對象有關的所有內容。然後，Azure搜索將此視圖的輸出索引爲我的用戶界面，以便稍後發出搜索查詢以查找相關記錄。對象具有我們可能想要搜索的各種屬性（視圖中的列）。就目標數量和屬性的不同來源而言，視圖是相當大的，因此性能是一個主要關注點。

我有一個新的屬性，我需要添加到這個扁平視圖。每個對象在這個TableN它具有以下結構

ObjectId SubNo SubValue 
A   Sub5 0 
B   Sub1 0 
B   Sub2 1 
B   Sub.. .. 
B   SubK 0   

現在我需要添加這個新屬性（AttrN）有0到多條記錄，這樣我可以索引的對象文檔（如天青搜索調用它）包含本新屬性。扁平的看法是這樣的：

ObjectId Attr1...  AttrN  
A  abc.....  {Sub5:0} 
B  abd.....  {Sub1:0,Sub2:1,...SubK:0} 

我的困境是：

如果我平了補充一點，串接對象的不同子值的CTE，視圖的性能惡化200％至700％。該cte使用mssql的stuff和for xml。執行計劃確實顯示總成本的〜8％爲此for xml聲明。我知道這會對性能產生影響，因爲我將更多的表格/視圖添加到扁平視圖中，但是我受到的影響程度相當高。

如果我外面加入我的ObjectFlattenedView直接TableN，那麼我的視圖將具有對象的記錄等於1對象在TableN中的記錄數。這使Azure搜索結果處理變得複雜化，例如從搜索中獲取多少條記錄並執行分頁，因爲對象可能有來自TableN的0到M條記錄。

有沒有人遇到類似的問題，你有模式，你可以建議我處理這種情況要麼在SQL服務器端提供適當的行集或Azure搜索端處理0：每個對象（文檔）的M個記錄？

Answer 1

不確定下面是否會完全解決您的問題，但可能有幫助。一些觀察：

1. 而不是創建一個單一的尤伯杯視圖壓扁的一切，你可以設置多個數據源/索引對所有寫入相同的搜索索引 - 只要他們都對文檔ID一致，您可以合併數據並從多個來源逐個組裝您的Azure搜索文檔。

2. 要處理值數組，Azure搜索具有Collection（Edm.String）字段類型。由於SQL本身不支持數組，因此可以使用JSON數組格式（例如[「a」，「b」，「c」]）生成字符串字段，並使用this article中描述的jsonArrayToStringCollection函數。

HTH！