爲什麼應該（或不應該）搜索查詢只返回文檔ID？

Question

因此，對於一個新項目，我正在爲電子商務網站構建一個系統。我們的想法是從供應商處進口產品，而不是直接將其插入到我們的目錄中，我們會將所有信息存儲在一個臨時區域中。每個供應商都有自己的舞臺（即數據庫中的表格），然後我將多個舞臺區域拼合成一個單獨的實體（目前只有一張桌子，但稍後可能放到Sphinx或Solr中）。然後，我們的採購員將能夠搜索分期產品的相關字段（名稱和說明），並顯示匹配的產品清單，然後選擇將這些產品推入實時目錄。搜索將查詢單個表格（展平區域）。

我的設計調用只在單個拼合表中存儲可搜索和可過濾的字段 - 例如，名稱，描述，supplier_id，supplier_prod_id等。搜索查詢將僅返回匹配項的ID和類（supplier_id），該類將用於識別產品來自哪個分段區。

另一個高級工程師感覺扁平檢索表應包括其他元字段（這將不被搜索），但是從階段「推」的產品，以住目錄時，都可以使用。他也認爲查詢應該返回所有這些其他信息。

我感到非常強烈，只有在扁平表中具有可搜索字段，並且搜索只返回可用於獲取關於產品的所有其他必要元數據的類/ id對（簡單select * from class_table where id in （1,2,3））。

我的理由之一是，這將使後來更容易將展平的表從數據庫切換到像sphinx或solr這樣的搜索服務器，並且其餘代碼不必僅僅因爲實現搜索已更改。

我在正確的道路上嗎？我如何說服其他工程師爲什麼只保留可搜索字段並僅返回ID是重要的？或者更具體地說，爲什麼一個搜索應用程序只返回對象的ID？

Answer 1

我認爲你是在正確的道路上。如果這些其他字段沒有提供唯一標識分階段項目或允許用戶過濾分階段項目的價值，則數據基本上是無用的，直到項目被推送到實況環境。如果其他工程師認爲額外的元數據將幫助用戶做出更明智的決定，那麼您可以使這些額外的字段可搜索（從而滿足您對錶格的陳述目的）。

唯一的原因我可以考慮預先獲取其他不可搜索的數據，以推動實時環境的性能改進。

Answer 2

在獅身人面像的情況下，它只返回文檔ID和命名屬性回到你啦（屬性是數字數據，在大多數情況下）。如果你需要的話，我會說你已經有了正確的想法，因爲其他元數據只是一個簡單的JOIN而已。

Answer 3

您應該使用每種工具做最好的事情。全文搜索引擎，如Solr或Sphinx，擅長搜索文本字段並快速排名。它在以類似選擇的方式檢索存儲的數據方面沒有特別的優勢。數據庫爲此進行了優化。所以，是的，你走在正確的道路上。請參閱Search Engine versus DBMS瞭解決定在搜索引擎中存儲什麼的其他問題。

Answer 4

。你可以把Solr的一個強大的指標，因此，作爲一個指數給出的ID後面，這將是合乎邏輯的Solr的不一樣。

您可以使用solr查詢參數fl來詢問僅標識符的結果，例如fl=id。

但是，還有一個功能需要solr還給你一些數據：在匹配的文檔中突出顯示搜索項。如果你不需要它，那麼使用solr來檢索標識符是沒有問題的（我假設你只需要文檔列表，並且沒有其他功能，如方面，相關文檔或拼寫檢查）。

也就是說，應該如何在你的搜索功能中建立你的對象，無論是從數據庫中使用唯一solr來檢索ID，還是從solr返回的字段（提供它們被存儲），或者甚至是兩者的混合。思考solr來獲得'突出顯示'的內容字段和數據庫的其他人。同樣，如果你不需要突出顯示，這不是一個問題。

Answer 5

我使用Solr的數以千計的文件，但只返回的ID，原因如下：

對於Solr的： - 如果一些同步錯誤追加，這不是一個大問題（尤其是在你的情況，顯示不同的價格可能是一個大問題...它就像項目將不在正確的位置，但數據是正確的） - 你將節省大量的時間，因爲當你不要求Solr返回文檔的「描述」（我的意思是很多文字）

對於您的數據庫： - 你可以緩存你的結果，所以用一個ID更快（你不需要每次來自Solr的所有數據!!!） - 你以相同的方式建立你的結果（你不需要一個特定的方法當你想從Solr建立html，並從你的數據庫中建立其他方法）

我認爲還有很多...