我的客戶正在要求將基於「建議」的查找添加到特定的表單域。 換句話說，當您開始在字段中輸入內容時，應該有一個「Google樣式」彈出窗口，其中顯示可能的結果以供選擇。將會有「成千上萬」的可能建議順序 - 這是我目前對數量的最佳估計。.NET vs SQL Server - 重複搜索的最佳做法
使用AJAX發送/檢索結果，我的問題是，是否最好在.NET緩存中存儲所有建議並在那裏處理，或者最好是在SQL Server上爲每個SQL Server運行一個基於存儲過程的查詢請求？
這將使用.NET 2.0和SQL Server 2005
你的瓶頸將把數據從服務器傳輸到瀏覽器。您幾乎可以立即從數據庫中輕鬆生成大量結果，但它將永遠返回到瀏覽器。
您必須找到一種方法來限制服務器返回的結果，以便您只能獲取用戶現在必須看到的內容。
當您將數據流量降低到合理水平時，您可以開始查看優化服務器部分。考慮到用戶輸入結果時往往是先前結果的一個子集，例如一些緩存和邏輯應該很容易。 「帽子」的匹配是「哈」匹配的一個子集。
當我看過「建議您鍵入」在SQL Server環境中進行搜索類型，我已經看到了使用某種性能最好一個緩存機制，通常是一個分佈式的方法 - 通常就像一個memcached。即使您的代碼進行了優化，您的數據庫也會得到很好的調整，並且您的查詢只需要調用< = 10ms，處理並返回，仍然是10ms。
謝謝邁克。對於你是否說10ms響應是好事還是壞事，有點不清楚。我個人覺得在500ms響應下（比如說）並不是什麼問題，因爲它並不是什麼重要的瞬間 – freefaller
我說的是10ms會很好，但是我用這個數字來感覺即使是很棒的性能通過堆棧調用的DBMS有時會對執行搜索建議類型搜索的用戶感到遲緩。在我的示例中，10ms可能是錯誤的持續時間，但我的觀點是 - 我認爲您會通過緩存方法獲得更快的建議。但我不認爲爲了這個目的而進行SP和優化數據庫/調用將是非常糟糕的，儘管如此，速度並不快。 –
公平 - 謝謝Mike – freefaller
這取決於物品的數量。如果您可以在.NET進程中緩存項目而不會耗盡內存，則會更快。
但是，如果不能這樣做，你堅持訪問每個請求上的數據庫。存儲過程將是一個很好的方法來做到這一點。
但有一些設計模式可以引導你。我在開發類似於你正在做的事情時使用了以下兩個。
感謝Wouter - 這幾乎是我所經歷的思維模式。這兩種選擇當然是值得考慮的事情，但我擔心可能要下載和存儲在瀏覽器上的數據量。 – freefaller
在我寫的'動態搜索'應用程序中，我們限制了顯示的項目的最大數目爲10個。因此，對於每個按鍵，我們將緩存10個項目，並且當用戶鍵入更多字符時，我們可以更多地過濾列表。 –
有一招我每次使用時面臨着這樣的任務。不要在每次按鍵時都做。在滑動超時時間內啓動搜索。
這裏的意圖是僅當用戶在他/她的打字中暫停時才啓動搜索。通常我將超時設置爲.1到.2秒。在心理上它仍然是瞬間的，但它大大減少了你用來搜索的任何東西的負載。
我真的很喜歡這個想法，我肯定會把它作爲設計的一部分......感謝 – freefaller
這是一個偉大的觀點......而我越多考慮它，作爲谷歌搜索的用戶，我最終現在打字時本能地建立一個暫停。我會盡快輸入我認爲「足夠」的內容，然後稍微暫停一下，看看「是否得到它」。在搜索框中輸入時沒有建議，感覺像是個傻瓜，但:-) –
我認爲你在這裏遇到了一個大問題......特別是當人們在建議列表中搜索經常重複的單詞時。儘管您建議的緩存理念會增加用戶體驗，但它需要網站上每個用戶的緩存，這可能會增加服務器資源需求。 – freefaller
@freefaller：它不需要每個用戶的緩存，它可以利用查詢經常跟隨彼此的優勢。例如，它可以使用緩存的結果「ha」來產生「帽子」的結果而不需要查詢數據庫。 – Guffa
對不起，我一定錯過了一些東西，因爲我看不出它是如何與用戶特定的不同的。如果多個用戶同時在網站上（我希望他們是），那麼將不可能使用子集，因爲查詢很可能完全不同。 – freefaller