mysql - 建模多对多一元关系和 1:M 一元关系

Question

我回到数据库设计，我意识到我的知识有很大的差距。

我有一个包含类别的表。每个类别可以有许多子类别，每个子类别可以属于许多超类别。

我想创建一个包含所有子类别文件夹的类别名称的文件夹。（像windows文件夹这样的视觉对象）所以我需要对子类别进行快速搜索。

我想知道在这种情况下使用 1:M 或 M:N 关系有什么好处？以及如何实现每个设计？

我创建了一个 1:M 一元关系的 ERD 模型。（该图还包含一个费用表，其中存储了所有费用值，但在这种情况下无关紧要）

1：一元关系

这个设计正确吗？

多对多一元关系是否允许更快地搜索超类别并且默认情况下是最好的设计？

我更喜欢包含 ERD 的答案

score 3 · Accepted Answer

如果我理解正确，一个子类别最多可以有一个（直接）超类别，在这种情况下，您不需要单独的表。这样的事情就足够了：

在此处输入图像描述

显然，您需要一个递归查询来获取所有级别的子类别，但如果您在 PARENT_ID 上放置一个索引，它应该是相当有效的。

朝相反的方向前进（并获取所有祖先）也需要递归查询。由于这将需要搜索 PK（自动索引），这也应该是相当有效的。

如需更多想法和不同的性能权衡，请查看此幻灯片。

score 1 · Accepted Answer

在某些情况下，在关系数据库中维护多级层次结构的最简单方法是嵌套集模型，有时也称为“修改的前序树遍历”（MPTT）。

基本上，树节点不仅存储父 id，还存储最左边和最右边叶子的 id：

spending_category
-----------------
parent_id    int
left_id      int
right_id     int
name        char

这样做的主要好处是，现在您可以通过单个查询获得节点的整个子树：子树节点的 id 介于 left_id 和 right_id 之间。有很多变化；其他存储节点的深度作为父节点 ID 的补充或替代。

一个缺点是 left_id 和 right_id 在插入或删除节点时必须更新，这意味着这种方法仅适用于中等大小的树。

Branko 提到的维基百科文章和幻灯片比我更好地解释了这项技术。如果您想了解更多关于在关系数据库中存储分层数据的不同方法，还可以查看此资源列表。

2 回答 2