***** 业务对象成树型数据结构时发生的故事 *****

[beegee]

公司让我设计一个类似注册表的工具软件，用于存储管理业务系统中承树型关系的业务对象。
我的设计是：
ID Name Value ... ParentID
----------------------------
1 参数1 250 ... null
2 参数2 254 ... 1
3 参数3 256 ... 2
我的Boss暴不爽，认为应该这样：
ID Name Value ...
---------------------------
001 参数1 250 ...
001001 参数2 254 ...
001001001 参数3 256 ...
于是吵架(*&%*%#&$&(%!!I%O(*&()...
我Boss对OO技术是最反感的,（估计是我太热爱的原因,“凡是敌人拥护的我们就反对”--XXX伟人）所有我说不服他。大家给支个招，说说两种方案的优劣，好吗？说服我或者我Boss都可以...

[brightheroes]

晕死

呵呵

我还是认为第一种方法清晰

[eyestrong]

从执行效率上去说服，你用两种方法各写一个，然后让他看看
从编程难度和代码可读性去说服,......

[xiays]

第一个方法好,不过在逻辑层上要加上些限制,否则自己找自己时用递归遍历到树上时就会出现死循环,还有就是三点组成三角形关系也会出玩死循环.

[feilong215]

來學習的.

[dahuzizyd]

第二种方法也是很常用，这种方法在《Delphi5企业级解决方案应用与剖析》（机械出版社，刘艺著，现在好向到Delphi6了，不知这个内容还有没有）一书中有讲到。
大体内容就是要有一个变量来保存编码格式：

例如：100100100，100100101；编码格式就是“xxx,xxx,xxx”,最后根据这个编码来拆解字符串，相对的代码要比第一种长得多，但是效率好像要好些，在数据库里看某个记录就可用知道他的分类，如：电器－电视－长虹牌－30寸－纯平，根据它的ID很快即可以看出来，第一种方法就只能看到它的上级了，书在这里有下载，有兴趣的话可用研究研究：
http://www.chinaelevator.com/download/sort.asp?classid=16&Nclassid=190

[tangyanjun1]

以前，我做的系统是使用第一个得。
但是我现在突然觉得第二种方法更好了。
呵呵，不好意思。

[dahuzizyd]

上面的连接是电子书，在其中的第9章有Delphi的源码，如果实在拗不过老板，可以用来参考

[beegee]

To:dahuzizyd(你就是我心中的女神) 谢谢你！
该种方法算法不如第1种清晰，但Boss已经使用行政手段确定了第2种方案。所有这个Delphi源码对我很有帮助。先谢谢了，一定给分！

[beegee]

Any more？

[changezhong]

楼主够惨的，同情

[beegee]

感谢各位！
我已经将第一种方案的详细设计搞完了，有递归,代码量很少,与控件绑定时也很方便！为了增强读取参数的友好性，我在第一种方案中又添加了一个字段：(姑且叫方案3)
ID Name Value ... ParentID NamePath
--------------------------------------
1 参数1 250 ... null 参数1
2 参数2 254 ... 1 参数1\参数2
3 参数3 256 ... 2 参数1\参数2\参数3
大家也看到了,这一方面是为了让Boss看得顺眼,另一方面的确也可以避免在读取时做大量递归.但是这种方案要求在加入参数时作一些字符操作.
郁闷中回家,结果Boss电话打来,必须按照他的方案做,我的详细设计肯定要进行大调整.
最气人的是Boss居然认为他的方法代码会很少...又总说效率,我不知道一个以 "001001002001..." 这样长度都不定的字符串为主键的表能有多快...
而且现在他一不作二不休,要将业务系统中所有有树形的地方全都改造成着样:(

[binbin2000]

boss永远是对的。如果boss错了。你可以告诉他也许你的不对。呵呵。
其实我认为你可以考虑boss的方案。因为他的也可行。

[8u9]

习惯中，我们一般都是按照第一种方法来进行树的遍历的，第二种虽然听过，但是没有具体做过，你的Boss这么说，有这么说的道理吧，你做了第二种的和你自己的相比较一下就清楚哪个好，哪个坏了，也就把表设计拿出来，然后运行一下sql就可以看出效率了，前台页面都不用写的。

[wangj2001]

我们用的也是第一种方案，灵活性和效率都很高

[beegee]

:-(