传统的生成静态页面的方法大家都很清楚，无非就是以下两种：
方案一：
1、每增加/修改一个栏目的信息的时候，就生成一次该栏目（包括父栏目）的页面；
2、每增加/修改一篇文章的时候，就生成一次该文章的页面，还有与其相关的栏目（包括父栏目）的页面。
方案二：
1、管理用户先增加/修改栏目/文章，最后再批量地选择欲更新的栏目/文章生成静态。
那么，不管是方案一还是方案二都有以下几个共同点：
1、所有的静态页面都是由管理员来操作，而前台用户只要浏览即可；
2、当某一个栏目文章很多的时候，生成静态会非常地慢；
3、当批量移动/删除文章的时候，生成静态会非常地慢。
....
因为我也是从这两种方法中走出来的，而我有一个内网数据库系统有80多万数据，我切身的感觉到：如果大量地更新文章的时候，服务器快吃不消了；如果哪天感觉页面不美观了，更改模板的时候需要重新生成，简直是……
也有朋友建议我：将栏目/文章的内容输出到XML文件中，最终html通过asp/asp.net+XML+XSL来输出，如此一来可以避免换模板的烦恼……
但是我还是觉得不满意……
最近想到了一种思路，并初步在拥有80多万数据的内网数据库系统中试运行了，但不知道服务器负载会不会加大？？？
我是如此做的：
1、管理用户每修改一个栏目的信息的时候，就删除该栏目（包括父栏目）对应的静态页面；
2、管理用户每修改一篇文章的时候，就删除该文章对应的静态页面，还有与其相关的栏目（包括父栏目）对应的静态页面；
3、某一个具体的栏目/文章的第一个浏览用户访问时，先判断对应的静态页面是否存在，如果存在，则直接Server.Transfer到静态页面，否则生成静态页面内容后再Server.Transfer过去。
有人会问：这有什么目的？？
其实我也不能正确地回答你如此做是否可行，只是我个人觉得：一来，将管理用户生成静态页面的操作权限留给了第一个访问用户，避免了一段时间内大量地占用服务器资源，恐怕此时别想让网站被流畅的浏览（直到静态页面全部生成，使服务器资源被释放）；二来批量删除页面的效率肯定比批量读取数据库记录并生成静态高很多吧；三来嘛，不用生成全部内容，没人关心的内容就不生成静态，节省空间（玩笑话了）。