我們主要是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了。
這樣以后就不用為每個系統開發日志管理模塊了。并且還能獲取到統計某一個用戶在所有系統中活動記錄的額外增強（例如我們可以在服務器端將日志記錄兩份，一份按應用系統，一份按操做者記錄）～～
|