我有可以属于多个类别的食品，一个类别可以有很多 食物产品。类别本质上是分层的：
我正在尝试设计数据库架构，并牢记两个约束。我应该如何继续使用模式设计来支持这个？
作为另一个例子，我发现Stack Overflow有一个类似于这个...标签的系统。每个问题都有多个标签，每个标签都有多个问题。这是如何实现的？如何根据我的分类需求调整此设计？
答案 0 :(得分：3)
这是many-to-many关系。一个问题可以有很多标签，一个标签可以有很多问题。在数据库中，这表示有一个附加表（tag id和question id）。
答案 1 :(得分：1)
在大多数关系数据库系统中，多对多关系通常由两个数据库表组成，这些表包含有问题的数据以及链接它们的中间表。像这样：
Posts
--------
ID
Title
Content
Tags
--------
ID
Title
PostTags
--------
PostID
TagID
这通过中间表在Posts和Tags之间创建了一种间接关系。 （请注意，如果您真的需要中间表，也可以使用ID列，但可能不需要它。请记住，在此表中添加更多列可能会产生创建不直观建模的风险。通常不是什么大不了的事，但是在为数据建模时需要注意的事项。在此表中添加更多列可以使数据模型之间的“关系”成为模型本身。）
使用您的食物类别，您会增加额外的复杂性，因为类别是分层的。但是，这可能只能通过自引用列来实现。像这样：
Products
--------
ID
Name
Description
Categories
--------
ID
Title
ParentCategoryID
ProductCategories
--------
ProductID
CategoryID
这里的主要区别是Categories表现在有一个列，指向该表自己的ID。因此，您在该表中的Food记录中包含ID值，并且由于它是层次结构中的顶级记录，因此null的值为ParentCategoryID。然后，Organic记录将拥有自己的ID值，并会在其Food字段中使用ID记录的ParentCategoryID值。这会创建该层次结构，而不会给数据模型增加不必要的复杂性。
请注意，此设计本身并不会阻止某人将某些内容归类为 Food和Organic。如果不应该发生这种情况，那么您将需要进一步细化设计和约束以防止它。大多数情况下，这种事情在应用程序中得到了强化，但如果您只是为了获得数据完整性的额外保证，那么在数据库中也可以这样做。