花了近两周的时间，终于完成了程序的更新，将之前的固定二级分类的信息结构转换为无级分类的信息结构，可以说从本质上改进了程序，从而使整个程序更加健壮，类别的扩展也更加灵活，类别的布局将是真正意义的一棵树而不再是严格的二级树（终端信息类级不能增也不能减，即只能在第二级，而不能直接从第一级建立信息），尽管我之前写过一个无级分类程序用于管理类别，但功能很不完善，很快就被我废弃掉了。当然写那个程序还是有用处的，一方面让我明白无级分类的原理，另一方面也在此过程中开发了一些有用的功能，比如获取当前类别的路径，查询当前类别的下属信息（无级嵌套子类信息，而不只是直属下级信息）。现在的这个无级分类程序其实是利用现有的一个功能较为完善的程序修改的，我将那个无级分类做了扩展，还增加了一些功能的开关控制，这在我的工作中显得很重要，特别是对于一些相对简单的系统，客户往往是不懂技术的，面对他们，一些“晦涩难懂”的功能最好还是隐藏为好，就比如“N级排序”“合并类别”、“复位类别”等功能，通常都是隐藏的，甚至我还将“无级”分类转化为面对客户只有其所用到的最高级数的分类，比如，客户有个二级分类的产品系统，我的系统可以很方便的限制客户只能在我的“无级分类”系统上最多只增加到第二级分类。这次的修改正是将工作的成果移植了过来。话又说回来，即使只是移植，还是费了不少工夫。
　　尽管程序是变得健壮了，但如果不做特殊处理的话，程序的运行速度确会变缓慢了，这也是为什么我一直在为是否使用无级分类而犹豫不决的原因吧。比如现在的一条信息，如果想显示其完整的类别路径，是需要做多次查询的（不能用视图，因为层数不固定，即使能用，读取的速度也很受影响）。
　　之前的程序，用的是二级分类，尽管扩展性不好，但也有他的优点，那就是快，特别是运用我的设计思路，程序几乎没法再快了，（吹一下牛，呵呵！）之前考虑到网站的速度（这是排在安全之后的第二重要因素），类别与类别的关联我用的是类别名（而不是ID，这与通常的做法是不一样的），直接用类别名的好处是什么呢？我可以用一个表就显示信息的所有内容（尽管这会带来数据冗余），信息记录已经有其相应的一、二级类别名，从而无需做关联查询。尽管这会使类别更新时变得复杂（它会影响到所有下属类另及下属信息），但毕竟信息类别的更新的概率比较小，而且执行此动作都是在后台，不会对客户造成任何影响，换来的确是前台信息读取速度的提高，显然这是一件小牺牲高回报的事！事实上我开发的系统很多都是基于一个有五级分类的分类系统，这个系统尽管没有无级分类那样实现真正意义的类别（层次）动态化，但确做得比之前的奋力年华网的二级分类完善许多，一方面它的信息不需要固定属于某个级别（只要不超过第五级），另一方面五级分类已经足够现实的使用。根据实际情况，到现在我所接触的客户还没有哪个需要类别层次会超过个数目的，即便某些运用无级分类的系统，我为客户开辟的通常都不会超过四级。
　　当然那个五级分类系统也有它的弊端。一方面是它的表很多，至少要六个，尽管通常只用到一两级，但另外的几级还是要放在那里，否则程序会出错。另一方面就是前面提到的数据冗余性大。每条记录都有五个字段用来保存其类别信息（当然为了显示速度的提高，这是不可避免的）。还有一方面，就是后台程序显示复杂，比如一级另类的修改会影响到下属四级类别表及终端信息表，更新、删除类别的动作的程序显得很复杂。
　　前面提到如果不做特殊处理的话，无级分类结构的信息会使程序的运行速度变得缓慢，这是“时间”上的问题。进一步分析一下，“空间”上的问题是程序的运行也会耗费大量内存，因为类别的层次不固定（尽管实际只用到了两、三层），所以需要使用递归，而递归读取表将是一件很消耗内存的事（尽管可以使用迭代的方式处理，那样会少吃点内存，但程序不好写，可读性也很差）。我想我的算法水平也就这种水准了，要想让提高网站的整体运行效率，我想最有效的办法应该是生成静态。一旦生成了静态，前台就无所谓程序运行速度的问题了，而是完全取决于网站所属空间的服务器性能（或是该服务器分本给该空间的资源使用量）及浏览客户端的网络环境的问题了。但完全生成静态，确又是一件很花时间的开发工作，与我的业余不足时间形成了矛盾，于是折中的办法就是对一些关键位置进行静态生成处理，事实上现在就是这样做。现在的奋力年华的整个首页除了中间的随机图片及底部的网站统计，其它各位置都是由生成的静态模块组合而成（这些模块其实就是了些.html文件，读取的时候没有访问数据库，更没有复杂的算法，也就节省了时间），事实上这样的处理已经把整个首页的程序的运行速度提高了数十倍。
　　尽管算不上什么大功告成，但也算是阶段性的胜利了。祝贺一下。呵呵！