我们主要是web应用，web规模也不能确定，有可能一天几千万甚至上亿的PV，也有可能根本没人用。最初设计guzz的目的就是让大型网站和小型网站一样设计编写，因为谁也不知道这个应用上去以后有多少人用，同时解决系统被要求页面天天改来该去的问题。
使用guzz以来的效果：
1. 框架性能上没有看得出的快慢区别。我觉得不会比hibernate和biatis慢，我看过他们的一些代码，流程挺复杂的。guzz很简单，整个持久化过程需要转手的类至少要比这两个少很多。
2. 以前我们用hibernate较多，一般数据库设计就是一个库，读写全部做。现在在设计时大家脑子里面直接就是分出3个数据库（可能部署在1台mysql上）--业务主库，临时信息库，日志库，然后把表分到不同的库中。然后数据库安装时直接主从安装，主从使用。虽然看起来库复杂了，但程序上没有任何成本代价，基本上已经形成一种设计流程。这种模式感觉可以作为最佳实践。
3. 编程上，一开始开发人员还是建个spring action类 + 在dao和manager中增加需要的方法 + 修改dispatcher-servlet.xml配置映射 + jsp实现view。但现在很多功能都是直接jsp，用taglib直接读库，基本上后台的读数据库操作页面已经看不到action的影子了。java代码比先前的工程，同样的功能少了大概60%-70%。
4. 我们的系统一般后台功能比较复杂，以往编辑要改点东西大家都很郁闷。不过现在抵制少了很多，基本上就是改改jsp或者在复制1个新的jsp改改，然后传到服务器上，一大堆集群机器的重启工作都免了，无论是开发还是部署都很省事。和php差不多。
guzz1.2.7分表和自定义表的应用实例：
我们有1套调查系统，使用了这项技术，也是第一个线上测试。每个调查都不太一样，需要网友填一些东西，需要填什么，填的个数类型都不定。一个调查进行过程中，或者结束后要求对数据进行统计报表。统计的内容可能也包括那些自定义的填空题。
在1.2.7之前，我们解决方案是：将所有自定义的调查项，按照key-value生成一个xml字符串，存储到数据库大字段中(Mysql text字段)。需要统计时，根据mysql5.1对xml支持的新特性使用ExtraValue函数解析这个xml生成一个新表（create table xxxx select ExtraValue(xx) as a, .....from 主调查记录表），然后在根据新的xxxx表统计。每次都要手工来弄，非常繁琐。
1.2.7，使用切表和自定义属性后，现在的解决方案：每次创建投票并建立好自定义调查项（自定义调查项存储在数据库中），根据这些自动生成一个mysql create table的语句，创建好需要的表。在配置CustomTableView动态的映射用户提交的数据存储到对应的表中。完全自动，后续处理简化了很多。
而且由于整个过程是实时的，以前的过程是手工的，所以很多线上的报表功能也可以开发了。开发也非常简单，我们用guzz jsp tablib直接读库，像操作普通java属性一样操作自定义属性，一个类型的表报1个jsp。特殊调查的特殊报表也就是往服务器上放1个特殊处理的jsp，应用都不用重启，非常方便。
guzz1.2.7分表和自定义表的下一个应用计划：
这是一个计划，还没有做，不过我们准备很快就开始做。
我们的所有系统对日志都有要求，日志必须记录！但日志的开发很烦人，全是没有技术含量的重复工作。我们准备开发一个日志服务，所有系统以后就不用开发日志了，直接使用这个服务。日志服务分为服务器端和客户端。
服务器端：
一个标准的java web系统，有日志数据库，用来存储所有系统的日志信息，并提供查询和统计等界面。如果有人需要查日志，就到这个系统来查。
服务器端有1个应用数据库，用来创建和管理授权的应用系统。1个新的应用上线的时候，在这里创建一个应用和他的授权码，然后录入他的个性日志字段和数据类型（类似上面提到调查的个性选项），服务器自动在数据库中给他创建1个日志表，用来存储这个应用的日志数据。我们准备按季度分表，让每个日志表1个季度分成1张子表。
客户端：
实现一个标准的guzz service，提供日志插入接口
- public void log(UserLog log) ;
每个系统开发时，将日志服务的jar包放到工程中，并在guzz.xml中声明此服务，代码直接调用就OK了。
这样以后就不用为每个系统开发日志管理模块了。并且还能获取到统计某一个用户在所有系统中活动记录的额外增强（例如我们可以在服务器端将日志记录两份，一份按应用系统，一份按操做者记录）～～
|