数据库建模：具有 1 个或多个类别的产品

Question

我正在研究一种数据库设计，允许产品属于 1 个或多个类别。类别可以是父子关系。到目前为止，这是我所拥有的：

==================
product
==================
product_id
name

==================
category
==================
category_id
parent_category_id
level
name

==================
product_category
==================
product_id
category_id (leaf node only)

问题

1. 设计好看吗？
2. 我只关心product_category->category_id 中的叶节点是否正确？ （我想我可以利用这些信息从叶节点一直到根节点）
3. 给定一个产品，我如何获得该产品所属的类别树？
4. 给定一个类别（类别树中的任何级别），我如何获得归类于该类别下的产品数量？
5. 我还需要查看其他任何问题吗？

Answer 1

您提供的内容看起来像是数据库中树的正确设计。但是，您的查询可能会变得复杂，并且您会发现自己需要针对某些任务进行多次查询，例如在遍历深度时每个级别都需要一个查询。

但是，数据库中的树实现也存在完全不同的方法。这有点违反直觉，但是当您查看查询简单性的好处时，很明显它有很多优点。

阅读：http://articles.sitepoint.com/article/hierarchical-data-database

---

此外，如果您使用像 Doctrine 这样的 ORM 来为您实现树以及操作，可能会更好。

Answer 2

1. 是的 - 多对多交集表是正确的（一个产品可以属于多个类别，一个类别有多个产品）。

2. 我同意这里也只放叶子。我希望您主要希望在其特定类别中显示产品，但会有滚动到父级的子查询，此时您可能已经在类别表中找到名称等。 - 经验法则，从反规范化开始，然后根据性能需要进行规范化。

3. product_category 表的内部联接（如果您想查看 SQL，请告诉我）。

4. 给定一个类别（类别树中的任何级别），我如何获得归类于该类别下的产品数量？ （通过连接和计数轻松完成 - 与上述相同）。

5. 随着您的前进，您可能会发现更多查询，但这就是紧急设计的美妙之处:)

Answer 3

正如其他人已经说过的那样，您的设计还可以。只是一个想法：
可能可以根据您正在建模的业务以更简单的方式表示类别的层次结构。例如：

CategoryId    Name
==========    ==========
1             Food
11            Chocolate
12            Dairy
121           Yoghurt
2             Grocery
etc...

如果这在您的域中可用，我认为它可以使您的设计更容易。