千
千中元
Unregistered / Unconfirmed
GUEST, unregistred user!
本来以为昨天已经攻克难关，以后可以过上边喝茶边聊天边写代码的幸福生活了。
谁知。。今天看了看目前项目的数据库表结构，大吃易经，好像不是按照关系型
设计的。
比如VOD节目类型表中的数据是这样的：
节目类型ID 节目类型名称 节目类型父ID
123 MTV 0
2342 歌曲 1
2334 革命歌曲 2
23456 江大为所有革命歌曲 3
23459 三毛所有革命歌曲 3
。。。。。。。。。。。。。 4 等
然后，要求在树中出现:
MTV(父类id为0的) ______革命歌曲（父类型id为2）
|_____________歌曲(父类型id为1)----|
|____影片(父类型id为1) ------资本注意歌曲
这样设计出来的数据库好像和以前的树型结构（关系型之前的是什么结构？记不清名字了，好像叫做树形）相同阿。如果拆分成多个关系表，
做出来这个树形比较简单，而且也可以和DataSet控件直接连起来，达到与其他
的数据感知控件共享DataSet的目的。
但是，一句“要让客户能够随意的增加分类的深度”，也就是要
能够随心所欲的增加父类型ID的数目4，5，6，增加这个树的纵深把我难住了。
而且我感到这样的表是一个早已经淘汰的结构。
唉，唉，作出来3层，4层，5层，如果给出的是几个关系表，而且这个层数固定，
都没问题啊。现在一天只喝了一小杯白开水，现在知道为啥大家不愿意做数据库
项目了
谁知。。今天看了看目前项目的数据库表结构，大吃易经，好像不是按照关系型
设计的。
比如VOD节目类型表中的数据是这样的：
节目类型ID 节目类型名称 节目类型父ID
123 MTV 0
2342 歌曲 1
2334 革命歌曲 2
23456 江大为所有革命歌曲 3
23459 三毛所有革命歌曲 3
。。。。。。。。。。。。。 4 等
然后，要求在树中出现:
MTV(父类id为0的) ______革命歌曲（父类型id为2）
|_____________歌曲(父类型id为1)----|
|____影片(父类型id为1) ------资本注意歌曲
这样设计出来的数据库好像和以前的树型结构（关系型之前的是什么结构？记不清名字了，好像叫做树形）相同阿。如果拆分成多个关系表，
做出来这个树形比较简单，而且也可以和DataSet控件直接连起来，达到与其他
的数据感知控件共享DataSet的目的。
但是，一句“要让客户能够随意的增加分类的深度”，也就是要
能够随心所欲的增加父类型ID的数目4，5，6，增加这个树的纵深把我难住了。
而且我感到这样的表是一个早已经淘汰的结构。
唉，唉，作出来3层，4层，5层，如果给出的是几个关系表，而且这个层数固定，
都没问题啊。现在一天只喝了一小杯白开水，现在知道为啥大家不愿意做数据库
项目了