62,614
社区成员
发帖
与我相关
我的任务
分享
...全文
请发表友善的回复…
发表回复
overcast 2004-08-26
- 打赏
- 举报
嗬嗬，只能说各有千秋了，但是楼主说是通用的
如果照你这么设计的话，如果我需要找某个节点的所有子节点，是不是需要用like来匹配，当数据量很大的时候，你觉得效率会很高？？
按照我的想法，n深的树最多只要n次查询就出来的，递归当然是不用的，除非你的算法够滥
当然，如果知道n很浅但是数据量很大的话，我相信这样的算法会效率会比较高
我相信按照你这么做的话，实际上是不能支持很深的树的，除非把主键设得很长，呵呵
作为通用算法的话，是需要考虑各种情况的
如果照你这么设计的话，如果我需要找某个节点的所有子节点，是不是需要用like来匹配，当数据量很大的时候，你觉得效率会很高？？
按照我的想法，n深的树最多只要n次查询就出来的，递归当然是不用的，除非你的算法够滥
当然，如果知道n很浅但是数据量很大的话，我相信这样的算法会效率会比较高
我相信按照你这么做的话，实际上是不能支持很深的树的，除非把主键设得很长，呵呵
作为通用算法的话，是需要考虑各种情况的
AllError 2004-08-26
- 打赏
- 举报
呵呵，楼主是要求提取数据时效率高。然后数据库通用。
AllError 2004-08-24
- 打赏
- 举报
哎，你不听老人言，吃亏在眼前。如果你是做应用，有谁没事改关键字啊。如果你只用ID和Pid你能一次就把一颗树检索出来吗，你能一下子把所有子节点找出来吗。搞个递归你觉得效率好吗。当然这种方法也有缺点，就是某字段有些浪费。不过为了方便，浪费点应该还是值得的
flyxxxxx 2004-08-24
- 打赏
- 举报
参考:
http://community.csdn.net/Expert/TopicView.asp?id=3190905
http://community.csdn.net/Expert/TopicView.asp?id=3190905
lakesea 2004-08-24
- 打赏
- 举报
overcast(Good Good Study)：
生成一棵树其实只用superID、ID足以，但是我觉得对一棵树superID、ID的规划更应该从你都实际情况出发。如果你的树节点不会从一个节点移动到另外一个节点，只是会增删节点，那我觉得用superID和ID关联可能效率要高一些。比如你要删除一个节点下的所有子节点，你就不用一次一次循环的从数据库中去检索。
但是如果你的节点经常要变换位置，那我的方法就不是很可取了，但是如果superID和ID之间没有什么关系的话，在需要删除或是查找节点之间的关系的话又十分困难。不知道在这种情况下是不是可以增加一个字段来表示之间的关系。
我一般做的树都只是增删，很少有移动节点位置的，所以对第二种没有深入做过。
生成一棵树其实只用superID、ID足以，但是我觉得对一棵树superID、ID的规划更应该从你都实际情况出发。如果你的树节点不会从一个节点移动到另外一个节点，只是会增删节点，那我觉得用superID和ID关联可能效率要高一些。比如你要删除一个节点下的所有子节点，你就不用一次一次循环的从数据库中去检索。
但是如果你的节点经常要变换位置，那我的方法就不是很可取了，但是如果superID和ID之间没有什么关系的话，在需要删除或是查找节点之间的关系的话又十分困难。不知道在这种情况下是不是可以增加一个字段来表示之间的关系。
我一般做的树都只是增删，很少有移动节点位置的，所以对第二种没有深入做过。
overcast 2004-08-23
- 打赏
- 举报
问几个问题
1，如果以及记录了SUPERID，为什么还要吧ID设置为SUPERID开头？检索的时候当然是根据SUPERID=#VALUE#来查
2，如果用PID+分隔符+ID来做主键的话，如果一个记录的PID修改了，是不是需要修改这个纪录的ID?这样的话如何保证其他表的记录引用了这个字段的主键作为外键？另外修改主键有时候效率很低，除了需要索引之外，还要检查其他表的外键引用。
实际上，应该是两个字段PID和ID（这一点和lakesea(虚无飘渺)一样），而不是合并起来，在查询的时候似乎SQL不能返回一棵树，而是返回一个记录列表，我的做法是根据PID排序，然后在程序中生成树结构，但是这样的做法在树很深的时候很麻烦，而且结果集的冗余数据会很多，这样的情况下可以用一些变通的方法，比如对于n深的树，可以查n次，每次只查第i级的数据，然后把所有i级的id作为第i+1级的pid。
在表的设计上，如果每一级数据都是一样的话，可以做一个表，加一个自引用，这样可以实现无限量级的树。
1，如果以及记录了SUPERID，为什么还要吧ID设置为SUPERID开头？检索的时候当然是根据SUPERID=#VALUE#来查
2，如果用PID+分隔符+ID来做主键的话，如果一个记录的PID修改了，是不是需要修改这个纪录的ID?这样的话如何保证其他表的记录引用了这个字段的主键作为外键？另外修改主键有时候效率很低，除了需要索引之外，还要检查其他表的外键引用。
实际上，应该是两个字段PID和ID（这一点和lakesea(虚无飘渺)一样），而不是合并起来，在查询的时候似乎SQL不能返回一棵树，而是返回一个记录列表，我的做法是根据PID排序，然后在程序中生成树结构，但是这样的做法在树很深的时候很麻烦，而且结果集的冗余数据会很多，这样的情况下可以用一些变通的方法，比如对于n深的树，可以查n次，每次只查第i级的数据，然后把所有i级的id作为第i+1级的pid。
在表的设计上，如果每一级数据都是一样的话，可以做一个表，加一个自引用，这样可以实现无限量级的树。
thankyou 2004-08-23
- 打赏
- 举报
ding
tanyun1111 2004-08-23
- 打赏
- 举报
表:
ID NAME .... PARENT_ID
ID是自动编号,NAME ....是其他列名,PARENT_ID对应ID,就是说如果PARENT_ID等于0,那么NAME就是第一节点,如果PARENT_ID等于其他记录的ID,那么PARENT_ID所对应的NAME就是其他记录的子节点,依次类推,可以无限循环下去
ID NAME .... PARENT_ID
ID是自动编号,NAME ....是其他列名,PARENT_ID对应ID,就是说如果PARENT_ID等于0,那么NAME就是第一节点,如果PARENT_ID等于其他记录的ID,那么PARENT_ID所对应的NAME就是其他记录的子节点,依次类推,可以无限循环下去
AllError 2004-08-21
- 打赏
- 举报
就是.我一般用PID+分隔符+ID.这样的好处是位数不限.字段大小根据实际情况调整了
lakesea 2004-08-21
- 打赏
- 举报
ID SUPERID 就这两个字段就可以表示一棵树了。其他的就是这颗树的相关信息了。
如果你要想在检索上效率高一些，ID和SUPERID需要有一定关系的。
比如SUPERID为10，那ID就应该是10××,位数根据你节点的多少调整。
这样检索时用superid like '10%' 就可以找出10下的所有节点以及其节点下的所有只节点
如果你要想在检索上效率高一些，ID和SUPERID需要有一定关系的。
比如SUPERID为10，那ID就应该是10××,位数根据你节点的多少调整。
这样检索时用superid like '10%' 就可以找出10下的所有节点以及其节点下的所有只节点
Frank1982 2004-08-21
- 打赏
- 举报
没看懂啊
说仔细一点吧
说仔细一点吧
