这个开发系统有个独特的好处，因为本身是mysql的，所以可以快速建立模型，马上用yii来生成类，无需单独用uml来折腾；
由于是分级分类结构，可以尽量分解大的复杂的功能为细小的各个分支去实现，可以很容易的逐步实现很大的功能

以上主要介绍开发思想，可能有人认为这个不过是用mysql+php来简单模拟svn，而且用mysql来保存很多功能设置不适合大型系统的需要，这点我非常赞同；
但是，这个系统可以简单的转换为标准的普通代码，而且使用的时候更为自然，方便自己开发，思考的时候顺其自然才能达到最高的开发效率，这是最主要的；
如果大家有参与讨论的多，我就把treedata的功能源代码放上来，现在还在逐步完善，增加更多功能，测试中

有个问题，好像本论坛发帖中的 隐藏功能 没有了，是吧，舰长？

还有一种情况是，相同的功能有不同的常用实现方式，总不能整合到一个系统下吧
强行重复实现相同功能，逻辑上在实际中是不会发生的

关于把所有功能整合到一起，没有必要也没有可能，实际实用的功能是针对某个应用场景的，还是按各个常用情景类别来发布同类应用下常用的功能比较可行；
大海捞针就是说功能太多不好找了；
分专题是比较理想的方式；分了之后，任务量减少，还容易实现，大一统的架构，需要考虑很多整合的问题，而那个整合的工作结果又只能用于这个独特的整合系统中，不能推广应用，反而浪费精力
不知道是不是我理解错了，如果把所有功能做成一个整合到一起的实例系统，有点够呛；
如果做专题，倒是很赞成

说点题外话，现在很流行nosql，非结构数据库，我的这个treedata无限分级分类，其实对他们的一种用mysql的模仿：
nosql可以无限分级插入包含的文档，我这里也可以，而且我这里可以更直接的调用mysql强大的搜索功能，更成熟的应用部署经验

希望将来mysql是否能考虑更底层的实现这个treedata结构，以实现更高的性能

目前，我就觉得很自然的开发，用起来非常舒服

下面用图示来说明我的采集系统的------
现在这个开发系统非常好的一点就是我想的什么分类结构，很自然简单的就是可以真实实现的结构

[attach]850[/attach]

我在想这个系统需要什么结构的时候，我就先在 采集 这一项目下 我建立一个子项： 结构
然后，我在 结构下来考虑采集的基本元素：站点
那么我就在结构下建立一个子项 站点
如果做过采集的人都知道，很可能不同的任务有不同的初始链接，那么很自然的就有子项 初始链接，
一般同一个站点的初始链接的页面编码都一样，如淘宝都是gbk，其他的很多都是utf-8
不同的页面编码采集到的数据都要统一转换为对应数据的数据编码，否则会乱码
那么就再增加一个页面编码的子项

如果需要增加什么功能，我可以再增加
增加完了，我想实际应用到淘宝采集中，那么我就建立一个专门放各个站点采集的项：实例 下
（通过复制结构的功能，然后更改名称即可）

这已经是yii的标准功能，其中引用的
zii.behaviors.CTimestampBehavior
就是提供这个功能的组件

这是简明的存储方式，把更新和建立都放到更新时刻字段中记录