树状结构的存储与管理，是每一个在关系型数据库平台上工作的程序员早晚都要遇到的问题。说大不大，怎么都能解决，说小不小，处理不好，有的是麻烦等着你。仁者见仁，智者见智，公说公有理，婆说婆有理（谁用机箱砸我？机箱是个好东西，乱丢会摔坏硬盘的，你看我话没说完你又把显示器丢了……），咳咳，好吧，闲话少说，我们从最大路的处理风格谈一谈吧。这里面的大部分内容并非我的独创，从很久很久以前，数据库程序员们就这样做啦。
树状表的结构化表达
在一切开始前，我们先就树状表的表示方式达成一个共识。在关系型数据库中，我们当然没有办法这样直接表示一个树：
a
b c
d e f g
相应的，我们会把它变形为平面表，这种变形让我想起拓扑几何：
r n1 n2
a b d
a b e
a c f
a c g
存储结构
稍有经验的朋友，大概都不会试着把树状结构一层一列的存进去了吧。这样做的问题是显而易见的：与表中存储的信息结构不同，表的结构应该是相对固定的，不能随便改动。而对于层数不能固定的普通树状结构，这是不可思议的。没有必要讨论过多的错误，我们选择一个相对正确的方式╠╠把树状结构抽象成适合关系数据库的形式。
只考虑某一个节点的话，和这个节点相关的信息是：它的唯一标识、父节点、子节点、数据信息。这其中只有子节点的数目不定。不过如果每一个节点都确定了自己的父节点，显然可以省略子节点。这样一来，一个节点需要存储三部分信息╠╠它的唯一标识、父节点、数据信息。一个理想的treeview表只需要三个节点就可以了，用sql语句来表达就是
create table [dbo].[treeview] (
[id] [char] (10) primary key,
[pid] [char] (10) foreign key references [dbo].[treeview],
[data] [char] (10)
)
