儲存在規範化表中並通過 JOIN 或單個 nvarchar 列中檢索並使用 LIKE 檢索是更好的主意（性能是關鍵）嗎？

注意：該應用程序實際上與網站或關鍵字無關，我在這裡使用它只是為了提供參考點以供討論。

我有一個實際上只是一串單詞的數據集。想想網站的“SEO” keywords。我有一個包含與此數據相關的數據的表。例如，說一個列表websites。

該數據集的關鍵場景是以雙向方式針對主數據進行檢索。也就是說，雖然我可以獲得一個包含所有相關關鍵字的網站，但我也應該能夠輸入一個關鍵字並獲得一個附加到該關鍵字的網站列表。關鍵字本身沒有附加（或可附加）其他元數據。

現在，考慮到檢索website -> keywordand時的查詢性能keyword -> website（顯著更多的案例）是最重要的，這些設計方案中的哪一個更有意義？

1. 在websites表中，我有一個 nvarchar 列，其中包含該網站的所有關鍵字的字元串，可能以逗號分隔。在這種情況下，檢索將在該行上使用 LIKE 運算符。
2. 我創建了一個單獨的keywords表，其中包含兩列 ( Id, Keyword)，將所有關鍵字放入其中，然後創建第三個表WebsiteKeywords，其中包含表websites和keywords表之間的映射。websites為了檢索，我們在websitekeywords和keywords表之間進行三向連接。

檢索被設計為通過 Web 服務基礎設施進行，因此在它認為它擁有所有數據之前，將有來自中間層的多次查找。因此，作為呼叫觸發的單個“搜尋”將導致多次此類查找，所有結果將由該中間層聚合，然後返回給呼叫者。

你有什麼建議？

絕對您想使用選項 2。您的查詢不僅會更快（= 總是比 like 更快），而且您還可以對該關鍵字欄位進行索引以獲得更快的查詢，並且您的儲存空間將大大減少，因為您不儲存每個網站的長關鍵字字元串。

選項 1 將始終強制執行 O(N) 操作（表/索引掃描），這會使該選項無法處理大量數據。如果您想要一個隨數據量擴展的解決方案，則必須使用選項 2。

如果行數很少（例如 3 左右），則選項 1 實際上可能更快。我懷疑我們在這裡談論的是那個案子。

引用自：https://dba.stackexchange.com/questions/93689