database-design - 为像 Yelp 或 eBay（许多类别和子类别）这样的网站设计数据库和关系的最佳方法是什么？

Question

他们是否有一个针对所有类别的表格和一个针对所有子类别的表格（以及另一个针对子子类别的表格，依此类推），还是什么？所有级别如何相互交流？

我是一个新手，开始从事一个可能具有这种复杂程度的项目，我很难理解这一点。

我正在使用 Rails，但我也很欣赏数据库模式的答案、进一步阅读的指针等。

Answer 1

我假设您在这里处理分层数据。

你只需要两张桌子。其中一张表用于类别和类别之间的关系。例如：

CategoryID CategoryName ParentCategoryID
----------------------------------------
1          Computers    NULL
2          Programming  1
3          Games        1
4          Python       2

另一个表用于存储与类别关联的数据。例如：

CategoryID ItemID Description
----------------------------------------------
4          1      Book – Programming in Python
3          1      World of Warcraft

第一个表包含将子类别链接到其父类别的外键列。这被称为“邻接表模型”。该模型的优点是易于理解，并且可以通过客户端代码轻松完成各种操作（例如，检索 Python 类别的路径 - /Computers/Programming/Python）（如果您不这样做）注意性能成本，因为您可能需要对数据库进行多次查询）。但是，如果您尝试在完整的 SQL 中执行此操作，可能会令人难以置信。例如，检索类别的路径将需要自联接。

构建此表的另一种方法是将类别和子类别视为集合和子集（称为“嵌套集模型”）。没有图表很难解释这个模型，而在 MySQL 中管理分层数据一文 似乎在解释概念方面做得更好（“邻接表”和“嵌套集”模型）。

Answer 2

我的建议是为每个使用单独的表，但是，“一个子类别是否可以存在于多个类别中”的问题也会改变结果。

如果有一对一的类别表 A，那么子类别表 B 与父类别 ID（来自 A）。

但是，如果它们可以存在于多个类别中，那么您可能会有一个规范化的表结构，其中您有类别 A、子类别 B 以及 Cat_ID 和 Sub_ID 的第三个表作为单个记录。

此外，与产品相关，您还将有一个规范化的表设置，其中有 Products 表、Category 表，然后是 Product_Categories 以及 product_id 和 category_id。这是无限可扩展的（上帝保佑）子类别表、product_subcategories、sub sub、sub sub sub、blah blah blah 等等等等。