我在围绕SQL闭包表时遇到了一些困难,并希望在理解我找到的一些示例时提供一些帮助。
假设我有一个名为sample_items
的表,其中包含以下分层数据:
id name parent_id
1 'Root level item #1' 0
2 'Child of ID 1' 1
3 'Child of ID 2' 2
4 'Root level item #2' 0
树结构应该是这样的:
id
| - 1
| | - 2
| | - 3
| - 4
为了便于查询树(例如查找特定id的所有后代),我使用the method described by Bill Karwin in this excellent SO post创建了一个名为sample_items_closure
的表。我还使用可选的path_length
列在需要时查询直接的子节点或父节点。如果我正确理解了这个方法,我的闭包表数据将如下所示:
ancestor_id descendant_id path_length
1 1 0
2 2 0
1 2 1
3 3 0
2 3 1
1 3 2
4 4 0
sample_items
中的每一行现在都在sample_items_closure
表格中有一个条目,供其自身及其所有祖先使用。到目前为止,一切都很有意义。
在研究其他闭包表示例时,I came across one that adds an additional ancestor for each row链接到根级别(ancestor_id 0)并且路径长度为0.使用上面的相同数据,这就是闭包表看起来像:
ancestor_id descendant_id path_length
1 1 0
0 1 0
2 2 0
1 2 1
0 2 0
3 3 0
2 3 1
1 3 2
0 3 0
4 4 0
0 4 0
为了提供更好的上下文,这里是一个在该网站上使用的选择查询,经过修改以适合我的示例:
SELECT `id`,`parent_id` FROM `sample_items` `items`
JOIN `sample_items_closure` `closure`
ON `items`.`id` = `closure`.`descendant_id`
WHERE `closure`.`ancestor_id` = 2
我有两个与此方法相关的问题:
问题#1:
为什么要添加一个额外的行,将每个后代链接到根级别(id 0)?
问题#2:
为什么这些条目的path_length为0,而不是前一个祖先的path_length + 1?例如:
ancestor_id descendant_id path_length
1 1 0
0 1 1
2 2 0
1 2 1
0 2 2
3 3 0
2 3 1
1 3 2
0 3 3
4 4 0
0 4 1
奖金问题:
为什么在闭包表中已经表达了树的完整结构时,一些示例仍然包含邻接列表(在我的示例中为parent_id
的{{1}}列)?
答案 0 :(得分:0)
You could use CTE's. They are made for exactly those use cases and have many great examples, which are close to your case.