MYSQL 递归操做

MYSQL 递归？

=====================

表： t_node

node_id int

node_name varchar2(45)

parent_id int

 

select * from t_node;

 

递归开始：

1.       向下查询：查找指定组下的全部分组 ( 不包括自己 )

select t2.node_id ,t2.node_name,t2.parent_id

from t_node t1, t_node t2 where t1.node_id=t2.parent_id and (t1.node_id= 0 or t1.parent_id= 0 );

分析：黑色部分为要查的组 id:0

结果：

2.       向下查询：查找指定组下的全部分组 ( 包括自己 )

select t2.node_id ,t2.node_name,t2.parent_id

from t_node t1, t_node t2 where t1.node_id=t2.parent_id and (t1.node_id= 0 or t1.parent_id= 0 )

union select t3.node_id ,t3.node_name,t3.parent_id from t_node t3 where t3.node_id= 0 ;

分析：黑色部分为要查的组 id:0

结果：

 

3.       向上查询：查找该组的全部父组

 

注意：发现一个问题，白马查不到。

上面的查询只能查 3 级，

 

转自：

分类表是一种典型的层次化关系的表，从数据库设计工做的角度看，让每一个分类记录的 parentId 字段指向它们父分类的 Id便可。 
把层次关系转化为数据表并不困难，并且层次还相对比较清晰，但在这种表面现象的背后还有许多难题在等待着用户解决。好比，咱们没法只用一个简单的 SELECT 就把指定分类的父分类或者子分类所有查询出来，而必须经过屡次查询才能解决这个问题（或者一次查出后，用程序来进行处理）。 
事实上，数据库设计和 SQL 编程有着千丝万缕的联系，很难将他们彻底区分开来，再者，若是 SQL 不足以把想要查询的数据从数据表里提取出来，那么，想拿出一个优秀的数据为设计方案就只能是一句空谈。 
想要经过数据表去管理和使用层次关系，得解决不少难题，而这些难题几乎都与 SQL 语言不能递归查询这一事实有关。以分类表为例： 
1 、只用一个查询就把指定分类的全部父分类所有查出来是不可能的 
2 、把完整的数据表还原为层次关系（树状）也是一个难点，仍是必须执行屡次 SQL 才能完成。 
3 、把指定分类下全部子分类所有查询出来 
4 、设计时，一个分类不能有两个父分类（例如： sql 语言既可以放在 database 分类中，但好象放在 programming 分类下也行，所以，若是 sql 语言有两个父分类仿佛才是合理的） 
5 、层次关系最担忧 的是留下循环引用隐患（好比手工删除数据或者添加数据时，很容易致使第 4 条的状况发生，数据库层次断链或者重复等） 
虽然有这些存在的问题，但并不是不可解决，而从上面这些难点来讲，层次关系每每会致使即便是一个相对简单的问题也须要不少条 SQL 查询才能得出答案，并且整个过程都至关慢。若是不使用层次关系（或者使用有限的层次关系），上述问题即均可以免。若是必须使用多级的层次关系，增长一些数据列或数据表来提供更多关于层次关系的信息，将有助于层次关系的解决方案变得简单一些。 
从范式的标准来讲，冗余是不对的，它会致使存储空间没必要要的浪费，增长数据库内部管理工做的负担，但为了提升应用程序的执行效率，冗余反而是一种至关简明的解决方案，所以，数据库设计实际上是一件多方妥协和折中的事。在数据库领域，通往同一个目标的道路每每有好多条，选择其中的任意一条，都意味着做出了这样或那样的妥协。作出什么样的妥协最有利这每每取决于数据库的具体使用状况：什么类型的查询发生的最为频繁？数据需不须要频繁修改？