----------

----------

ROOT

ROOT

ROOT

N11

ROOT

Node1-1

N12

ROOT

Node1-2

N13

ROOT

Node1-3

N21

N11

Node2-1

N22

N11

Node2-2

N23

N12

Node2-3

N24

N13

Node2-4

N31

N21

Node3-1

N32

N21

Node3-2

N33

N21

Node3-3

N34

N22

Node3-4

       归纳法第一步，当然是构造初值，查询子树的根节点就是标准的SQL，SELECT ID, DATA FORM TreeView WHERE ID = …，在这里有一个细节，查找表中所有的根节点（细心的读者可能早就发现，我们设计的这个TreeView可以存储任意多个树）可以通过SELECT R.ID, R.DATA FORM TreeView R WHERE R.ID = R.PID来实现。简单起见，我们就从这里起步吧。

       第二步，选择出前两层也不难，

SELECT R.ID, N1.ID, N1.DATA

FROM TreeView R

LEFT JOIN TreeView N1

ON R.ID = N1.PID

AND R.ID <> N1.ID

WHERE R.ID = R.PID

       我们要注意的是加蓝的部分，这是增加一层后做改动的部分。

       很容易，我们得到前三层，

SELECT R.ID, N1.ID, N2.ID, N2.DATA

FROM TreeView R

LEFT JOIN TreeView N1

ON R.ID = N1.PID

AND R.ID <> N1.ID

LEFT JOIN TreeView N2

ON N1.ID = N2.PID

AND N1.ID <> N2.ID

WHERE R.ID = R.PID

       同样的，我们重点观察加蓝的部分。相信经过这两步，大家会发现其中的规律。现在我们可以把这个过程自动化了……

       ……

       不知道大家是否还记得前几集里那个关于四色问题的笑话，我又一次犯了这样的错误。一个多月以来，我就陷在这里不能自拔。显然，我低估了问题的难度。这个问题似乎不能转化为一个简单表达式，只能通过一个递归的流程来实现。而流程化的程序又非SQL所长。这里面有着各种各样的麻烦。相信试过的朋友都有体会。现在我使用的架构问题是显然的，它需要明确知道到底从子树的顶点向下到底有多少层。所以，计算树的层数就首先被提了出来。

       但是，但是，但是……（我简直没脸见人啦）我一直找不到一个简洁优雅的方法。一个多月的时间就这么过去了。我不得不一点点放弃我的原则（此乃人生堕落之始啊）。最后，我得承认，要想写出一个优雅的树状表选择来，对我还是比较困难的。所以，在这一篇文章里，我们先讨论到这里，树状表的选择――其实应该说树状视图构造，还是留到下次再讨论吧。

上一页  [1] [2]