數據庫設計問題

Question

我在設計一個產品聚合器的數據庫。每個產品都有關於它來自何處，它的成本，它是什麼類型，價格，顏色等信息。用戶需要能夠根據這些產品類別搜索和過濾結果。我也希望有大量的用戶。我最初的想法是有一張大桌子，裏面的每一件產品都有一個信息欄和一個我需要能夠搜索到的東西的索引，但我認爲這可能是效率低下，許多用戶都在衝擊這一個表。我的另一個想法是組織數據庫以促進表格的樹狀導航，但因爲您可以搜索任何東西，所以我不知道如何組織表格。

關於一些良好做法的想法？

Answer 1

產品的一個表 - 數據庫旨在讓大量用戶在表上衝擊。

（來自評論）

您需要爲您的數據建模。這是通過查看你擁有的所有數據，確定什麼與什麼有關（一個表稱爲關係，因爲一行中的所有屬性都與候選關鍵字相關）。您沒有真正提供足夠的關於這些產品的數據（非結構化？）的範圍以及它們如何變化的信息。你會遇到困難，因爲鞋子有品牌，型號，尺寸和顏色，但書桌只有品牌，型號和完成？所有這些都會通知您的數據模型。通常你有一個產品表，其他東西鏈接到它。

其中一些屬性將是外鍵查找表，其他屬性（價格）將是簡單的標量。適當的索引，你會沒事的。對於高級分析，考慮一個以維度爲模型的星型模式，但可能不適合您的實時交易系統 - 取決於您的數據流/工作流程/交易。或者在交易數據庫中考慮其原理的一些好處。 Ralph Kimball是關於三維建模的良好信息的來源。

Answer 2

我沒有看到這裏的樹結構的任何需要。你可以使用單個表格。

如果你堅持樹結構與層次結構在這裏是一個example讓你開始。

Answer 3

對於基於文本的搜索以及易於啓動的&設計，我強烈推薦Apache SOLR。 SOLR API易於使用（特別是JSON）。數據庫對文本進行搜索的效果很差，我建議您確保它們能夠正確響應主鍵/唯一鍵查詢，並且這些是您應該編入索引的字段。

Answer 4

產品的一張表和產品類別層次結構的另一張表（你沒有具體說你有這個，但「樹狀的表格導航」讓我覺得你可能）。

我可以看到，如果您打算爲幾乎所有列編制索引，您可能會擔心索引過度導致問題。在這種情況下，最好對用戶可能搜索的前5或10列進行索引，除非用戶可以在任何列上進行搜索。在這種情況下，您可能需要考慮構建數據倉庫。也許你會想看看數據立方體，看看這些會有幫助...？

---

對於分層數據，你需要一個PRODUCT_CATEGORY表看起來像這樣：

ID 
PARENT_ID 
NAME 

一些樣本數據：

 
ID  PARENT_ID  NAME 
1     ROOT 
2  1    SOCKS 
3  1    HELICOPTER PARTS 
4  2    ARGYLE 

一些SQL引擎（如Oracle）讓你編寫遞歸查詢來遍歷單個查詢中的層次結構。在這個例子中，樹的根有PARENT_ID,NULL，但是如果你不希望這個列可以爲空，我也看到-1用於相同的目的。