mysql stores tree structure data

Analysis tree data

The tree structure data in JSON format needs to be saved to mysql.

The tree diagram is as follows: 
 
Analyzed into text as shown in the figure: 

The structure stored in the table is: 

need

There are two general data usage requirements for tree structures:

Display data for the entire tree

select * from treeNodes

• 1

Given a point, show the path taken to reach that point

a=select * from treeNodes where id='7'
b=select * from treeNodes where id=a.pid
c=select * from treeNodes where id=b.pid

• 1
• 2
• 3

... recursively to the Root node in turn.

You can also use the following methods to get the traversed path:

Method 1 uses a function to get all child node numbers

Create a function getChildLst to get a string consisting of all child node numbers. 

mysql> delimiter / 
mysql> 
mysql> CREATE FUNCTION getChildLst(rootId INT) 
-> RETURNS varchar(1000) 
-> BEGIN 
-> DECLARE sTemp VARCHAR(1000); 
-> DECLARE sTempChd VARCHAR(1000); 
-> 
-> SET sTemp = ‘$’; 
-> SET sTempChd =cast(rootId as CHAR); 
-> 
-> WHILE sTempChd is not null DO 
-> SET sTemp = concat(sTemp,’,’,sTempChd); 
-> SELECT group_concat(id) INTO sTempChd FROM treeNodes where FIND_IN_SET(pid,sTempChd)>0; 
-> END WHILE; 
-> RETURN sTemp; 
-> END 
-> // 
Query OK, 0 rows affected (0.00 sec)

mysql> 
mysql> delimiter ; 

use we directly use the find_in_set function with this getChildlst to find 

mysql> select getChildLst(1); 
+—————–+ 
| getChildLst(1) | 
+—————–+ 
| $,1,2,3,4,5,6,7 | 
+—————–+ 
1 row in set (0.00 sec)

mysql> select * from treeNodes 
-> where FIND_IN_SET(id, getChildLst(1)); 
+—-+———-+——+ 
| id | nodename | pid | 
+—-+———-+——+ 
| 1 | A | 0 | 
| 2 | B | 1 | 
| 3 | C | 1 | 
| 4 | D | 2 | 
| 5 | E | 2 | 
| 6 | F | 3 | 
| 7 | G | 6 | 
+—-+———-+——+ 
7 rows in set (0.01 sec)

mysql> select * from treeNodes 
-> where FIND_IN_SET(id, getChildLst(3)); 
+—-+———-+——+ 
| id | nodename | pid | 
+—-+———-+——+ 
| 3 | C | 1 | 
| 6 | F | 3 | 
| 7 | G | 6 | 
+—-+———-+——+ 
3 rows in set (0.01 sec) 

优点: 简单，方便，没有递归调用层次深度的限制 (max_sp_recursion_depth,最大255) ；

缺点：长度受限，虽然可以扩大 RETURNS varchar(1000)，但总是有最大限制的。

MySQL目前版本( 5.1.33-community)中还不支持function 的递归调用。

方法二利用临时表和过程递归

创建存储过程如下。 
createChildLst 为递归过程，showChildLst为调用入口过程，准备临时表及初始化。 

mysql> delimiter // 
mysql> 
mysql> # 入口过程 
mysql> CREATE PROCEDURE showChildLst (IN rootId INT) 
-> BEGIN 
->CREATE TEMPORARY TABLE IF NOT EXISTS tmpLst 
-> (sno int primary key auto_increment,id int,depth int); 
->DELETE FROM tmpLst; 
-> 
->CALL createChildLst(rootId,0); 
-> 
->select tmpLst.,treeNodes. from tmpLst,treeNodes where tmpLst.id=treeNodes.id order by tmpLst.sno; 
-> END; 
-> // 
Query OK, 0 rows affected (0.00 sec) 
mysql> 
mysql> # 递归过程 
mysql> CREATE PROCEDURE createChildLst (IN rootId INT,IN nDepth INT) 
-> BEGIN 
->DECLARE done INT DEFAULT 0; 
->DECLARE b INT; 
->DECLARE cur1 CURSOR FOR SELECT id FROM treeNodes where pid=rootId; 
->DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1; 
-> 
->insert into tmpLst values (null,rootId,nDepth); 
-> 
->OPEN cur1; 
-> 
->FETCH cur1 INTO b; 
->WHILE done=0 DO 
->CALL createChildLst(b,nDepth+1); 
->FETCH cur1 INTO b; 
->END WHILE; 
-> 
->CLOSE cur1; 
-> END; 
-> // 
Query OK, 0 rows affected (0.00 sec) 
mysql> delimiter ; 

调用时传入结点 

mysql> call showChildLst(1); 
+-----+------+-------+----+----------+------+ 
| sno | id | depth | id | nodename | pid| 
+-----+------+-------+----+----------+------+ 
| 4 |1 | 0 |1 | A|0 | 
| 5 |2 | 1 |2 | B|1 | 
| 6 |4 | 2 |4 | D|2 | 
| 7 |5 | 2 |5 | E|2 | 
| 8 |3 | 1 |3 | C|1 | 
| 9 |6 | 2 |6 | F|3 | 
|10 |7 | 3 |7 | G|6 | 
+-----+------+-------+----+----------+------+ 
7 rows in set (0.13 sec) 
Query OK, 0 rows affected, 1 warning (0.14 sec) 
mysql> 
mysql> call showChildLst(3); 
+-----+------+-------+----+----------+------+ 
| sno | id | depth | id | nodename | pid| 
+-----+------+-------+----+----------+------+ 
| 1 |3 | 0 |3 | C|1 | 
| 2 |6 | 1 |6 | F|3 | 
| 3 |7 | 2 |7 | G|6 | 
+-----+------+-------+----+----------+------+ 
3 rows in set (0.11 sec) 
Query OK, 0 rows affected, 1 warning (0.11 sec) 

depth 为深度，这样可以在程序进行一些显示上的格式化处理。类似于oracle中的 level 伪列。sno 仅供排序控制。这样你还可以通过临时表tmpLst与数据库中其它表进行联接查询。

MySQL中你可以利用系统参数 max_sp_recursion_depth 来控制递归调用的层数上限。如下例设为12. 

mysql> set max_sp_recursion_depth=12; 
Query OK, 0 rows affected (0.00 sec) 


优点 : 可以更灵活处理，及层数的显示。并且可以按照树的遍历顺序得到结果。 
缺点 : 递归有255的限制。

方法三利用中间表和过程

(本方法由yongyupost2000提供样子改编) 
创建存储过程如下。由于MySQL中不允许在同一语句中对临时表多次引用，只以使用普通表tmpLst来实现了。当然你的程序中负责在用完后清除这个表。 

delimiter // 
drop PROCEDURE IF EXISTSshowTreeNodes_yongyupost2000// 
CREATE PROCEDURE showTreeNodes_yongyupost2000 (IN rootid INT) 
BEGIN 
DECLARE Level int ; 
drop TABLE IF EXISTS tmpLst; 
CREATE TABLE tmpLst ( 
id int, 
nLevel int, 
sCort varchar(8000) 
); 
Set Level=0 ; 
INSERT into tmpLst SELECT id,Level,ID FROM treeNodes WHERE PID=rootid; 
WHILE ROW_COUNT()>0 DO 
SET Level=Level+1 ; 
INSERT into tmpLst 
SELECT A.ID,Level,concat(B.sCort,A.ID) FROM treeNodes A,tmpLst B 
WHEREA.PID=B.ID AND B.nLevel=Level-1; 
END WHILE; 
END; 
delimiter ; 
CALL showTreeNodes_yongyupost2000(0); 

执行完后会产生一个tmpLst表，nLevel 为节点深度，sCort 为排序字段。 
使用方法 

SELECT concat(SPACE(B.nLevel*2),'+--',A.nodename) 
FROM treeNodes A,tmpLst B 
WHERE A.ID=B.ID 
ORDER BY B.sCort; 


优点 : 层数的显示。并且可以按照树的遍历顺序得到结果。没有递归限制。 
缺点 : MySQL中对临时表的限制，只能使用普通表，需做事后清理。

存储结构对比优化

假设有如下一棵树： 

方法一存储父节点

要存储于数据库中，最简单直接的方法，就是存储每个元素的父节点ID。 
暂且把这种方法命名依赖父节点法，因此表结构设计如下： 
 
存储的数据如下格式： 
 
这种结构下，如果查询某一个节点的直接子节点，十分容易，比如要查询D节点的子节点。

select * from tree1 where parentid=4

• 1

如果要插入某个节点，比如在D节点下，再次插入一个M节点。 
只需要如下SQL：

INSERT INTO tree1 (value,parentid) VALUES('M',4);

• 1

这种结构在查找某个节点的所有子节点，就稍显复杂，无论是SELECT还是DELETE都可能涉及到获取所有子节点的问题。比如要删除一个节点并且该节点的子节点也要全部删除，那么首先要获得所有子节点的ID，因为子节点并不只是直接子节点，还可能包含子节点的子节点。比如删除D节点及其子节点，必须先查出D节点下的所有子节点，然后再做删除，SQL如下： 

select nodeid from tree1 where parentid=4 --返回8,9 
select nodeid from tree1 where parentid in (8,9) --返回10,11,12 
select nodeid from tree1 where parentid in (10,11,12) --返回空 
delete from tree1 where nodeid in (4,8,9,10,11,12) 

如果是只删除D节点，对于其它节点不做删除而是做提升，那么必须先修改子节点的parentid，然后才能删除D节点。 
正如上面演示的，对于这种依赖父节点法，最大的缺点就是无法直接获得某个节点的所有子节点。因此如果要select所有的子节点，需要繁琐的步骤，这不利于做聚合操作。 
对于某些数据库产品，支持递归查询语句的，比如微软的SQL Server，可以使用CTE技术实现递归查询。比如，要查询D节点的所有子节点。只需要如下语句： 

WITH tmp AS( 
SELECT * FROM Tree1 WHERE nodeid = 4 
UNION ALL 
SELECT a.* FROM Tree1 AS a,tmp AS b WHERE a.parentid = b. nodeid 
) 
SELECT * FROM tmp 

但是对于那些不支持递归查询的数据库来说，实现起来就比较复杂了。

方法二存储路径

还有一种比较土的方法，就是存储路径。暂且命名为路径枚举法。 
这种方法，将存储根结点到每个节点的路径。 
 
这种数据结构，可以一眼就看出子节点的深度。 
如果要查询某个节点下的子节点，只需要根据path的路径去匹配，比如要查询D节点下的所有子节点。

select * from tree2 where path like '%/4/%'

• 1

或者出于效率考虑，直接写成

select * from tree2 where path like '1/4/%'

• 1

 
如果要做聚合操作，也很容易，比如查询D节点下一共有多少个节点。

select count(*) from tree2 where path like '1/4/%';

• 1

要插入一个节点，则稍微麻烦点。要插入自己，然后查出父节点的Path，并且把自己生成的ID更新到path中去。比如，要在L节点后面插入M节点。 
首先插入自己M，然后得到一个nodeid比如nodeid=13，然后M要插入到L后面，因此，查出L的path为1/4/8/12/,因此update M的path为1/4/8/12/13 

update tree2 set 
path=(select path from tree2 where nodeid=12) --此处开始拼接 
||last_insert_rowid()||'/' 
where 
nodeid= last_insert_rowid(); 

这种方法有一个明显的缺点就是path字段的长度是有限的，这意味着，不能无限制的增加节点深度。因此这种方法适用于存储小型的树结构。

方法三存储关系表和深度

下面介绍一种方法，称之为闭包表。 
该方法记录了树中所有节点的关系，不仅仅只是直接父子关系，它需要使用2张表，除了节点表本身之外，还需要使用1张表来存储节祖先点和后代节点之间的关系（同时增加一行节点指向自身）,并且根据需要，可以增加一个字段，表示深度。因此这种方法数据量很多。设计的表结构如下： 
Tree3表： 
 
NodeRelation表： 
 
如例子中的树，插入的数据如下： 
Tree3表的数据 
 
NodeRelation表的数据 
 
可以看到，NodeRelation表的数据量很多。但是查询非常方便。比如，要查询D节点的子元素 
只需要

select * from NodeRelation where ancestor=4;

• 1

要查询节点D的直接子节点，则加上depth=1

select * from NodeRelation where ancestor=4 and depth=1;

• 1

要查询节点J的所有父节点，SQL：

select * from NodeRelation where descendant=10;

• 1

如果是插入一个新的节点，比如在L节点后添加子节点M,则插入的节点除了M自身外，还有对应的节点关系。即还有哪些节点和新插入的M节点有后代关系。这个其实很简单，只要和L节点有后代关系的，和M节点必定会有后代关系，并且和L节点深度为X的和M节点的深度必定为X+1。因此，在插入M节点后，找出L节点为后代的那些节点作为和M节点之间有后代关系，插入到数据表。 

INSERT INTO tree3 (value) VALUES('M');--插入节点 
INSERT INTO NodeRelation(ancestor,descendant,depth) 
select n.ancestor,last_insert_rowid(),n.depth+1--此处深度+1作为和M节点的深度 
from NodeRelation n 
where n.descendant=12 
Union ALL 
select last_insert_rowid() ,last_insert_rowid(),0 --加上自身 

在某些并不需要使用深度的情况下，甚至可以不需要depth字段。 
如果要删除某个节点也很容易，比如，要删除节点D，这种情况下，除了删除tree3表中的D节点外，还需要删除NodeRelation表中的关系。 
首先以D节点为后代的关系要删除，同时以D节点的后代为后代的这些关系也要删除： 

delete from NodeRelation where descendant in 
(select descendant from NodeRelation where ancestor=4 )； 

–查询以D节点为祖先的那些节点，即D节点的后代。 
这种删除方法，虽然彻底，但是它也删除了D节点和它原本的子节点的关系。 
如果只是想割裂D节点和A节点的关系，而对于它原有的子节点的关系予以保留，则需要加入限定条件。 
限制要删除的关系的祖先不以D为祖先，即如果这个关系以D为祖先的，则不用删除。因此把上面的SQL加上条件。 

delete from NodeRelation where descendant in 
(select descendant from NodeRelation where ancestor=4 )； 

–查询以D节点为祖先的那些节点，即D节点的后代。 

and ancestor not in (select descendant from NodeRelation where ancestor =4 ) 

上面的SQL用文字描述就是，查询出D节点的后代，如果一个关系的祖先不属于D节点的后代，并且这个关系的后代属于D节点的后代，就删除它。 
这样的删除，保留了D节点自身子节点的关系，如上面的例子，实际上删除的节点关系为： 
 
如果要删除节点H，则为 
 
总结： 
上面主要讲了3种方式，各有优点缺点。可以根据实际需要，选择合适的数据模型。

参考链接: 
http://blog.csdn.net/sky786905664/article/details/52742392 
http://langgufu.iteye.com/blog/1891798