建模多对多的一元关系和1：一元关系

我重新回到数据库设计，我意识到我在我的知识中有巨大的差距。建模多对多的一元关系和1：一元关系

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

我想创建一个包含所有子类别文件夹的类别名称的文件夹。（可视对象，如Windows文件夹）所以我需要执行子类别的快速搜索。

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

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

1:M unary relationship

是这样的设计是否正确？

多对多的一元关系可以更快地搜索超类别，并且是默认情况下的最佳设计？

我宁愿它包含一个ERD

来源

2012-07-20 Xitcod13

出于好奇，什么是“1：一元关系”？我使用“1：1”关系的术语“一元”（或者在某些情况下可能是“0-1：0-1”）。 – 2012-07-20 18:26:06

在数据库系统 - 设计，实现和管理（第9版）中给出一个课程的例子来解释一元M：N关系：在学校环境中，M：N递归关系可能更为熟悉。例如，注意图4.17所示的M：N “COURSE需要COURSE”关系如何实现在图4.21中。在这个例子中， MATH-243是QM-261和QM-362的先决条件，而MATH-243和QM-261是先决条件 QM-362 – Xitcod13 2012-07-20 18:49:30

如果我理解正确的答案，一个子类最多只能有一个（直接）超类，在这种情况下，你不需要一张单独的桌子。这样的事情应该已经足够了：

enter image description here

很显然，你需要一个递归查询，从各个层面得到的子类，但它应该是相当有效的前提是你穿上PARENT_ID的索引。

走相反的方向（并获得所有祖先）也需要一个递归查询。由于这需要搜索PK（这是自动编入索引的），所以这应该也是合理的。

对于一些更多的想法和不同的性能权衡，看看this slide-show。

来源

2012-07-20 18:39:05

好吧真棒，所以没有必要恐慌。我正在看一本书，我看到了各种各样的图表，我完全不记得它们，所以我跳到了结论。谢谢你的回答和链接:) – Xitcod13 2012-07-20 18:54:31

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

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

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

从这样做的主要好处是，现在你能得到具有单个查询的节点的整个子树：子树节点的ID位于left_id和right_id之间。有许多变化;除了父节点ID之外或者替代父节点ID，其他人存储节点的深度。

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

Branko提到的wikipedia article和slideshow解释技术比我更好。如果您想了解更多关于在关系数据库中存储分层数据的不同方式，请查看this list of resources。

来源

2012-07-20 18:57:03 Joni

很有意思。当你插入新的值时，我会阅读它看起来像很多工作要维护。 – Xitcod13 2012-07-20 19:03:55

建模多对多的一元关系和1：一元关系

回答

相关问题