版本控制主要是通過獲取檔案最近修改時間來實現的。具體來說包括以下步驟：1）系統啟動時，通過oracle中的sysdate函式取得資料庫伺服器的當前時間，並將客戶端時間與伺服器時間進行自動同步；2）臨時公文上傳到伺服器進行備份時，獲得檔案的最近修改時間並保存在資料庫中的updatetime欄位中；3）檢查本地檔案與資料庫備份檔案是否一致時，再次獲得本地檔案的最近修改時間，通過與資料庫中保存的時間進行比
較完成。
獲取檔案最近修改時間功能實現，主要是通過windows的api函式findfirstfile()獲得檔案屬性數據，該數據的ftlastwritetime屬性即為檔案的最後修改時間。值得注意的是，該屬性獲得的是用32位表示的檔案時間戳，為作業系統使用。要想轉換為用戶能看懂的本地系統時間，需要通過filetimetolocalfiletime()、filetimetosystemtime()以及systemtimetodatetime()函式進行轉換。
4 測試驗證
為了驗證依據上述分析設計的有效性，對已實現的公文管理系統進行了測試驗證。
4.1 實驗設定
試驗在2台pc機組成的區域網路內進行。資料庫伺服器的基本配置為piv 2.0g cpu，1g記憶體，120g硬碟，其上安裝了oracle 9i；客戶端pc機配置為piii 1g cpu，512m記憶體，80g硬碟，安裝了oracle客戶端和office XX軟體。
實驗數據集為某單位XX-XX.6產生的500個實際公文檔案，大小從50k到500k不等，平均大小約為200k。在其上進行了存儲開銷比較、查詢性能、自動歸檔性能以及全文檢索性能的實驗。
4.2 實驗結果
採用三種存儲方案對公文進行存儲，考查隨公文數增加不同方案存儲開銷之間的差異，如圖3所示。其中方案一為所有元素均分離存儲；方案二為僅存儲完整的公文檔案；方案三為本文採取的折中方案。
可以看出，方案一所需空間最小，方案二其次，方案三所需空間最大。這是因為，方案一僅保存了必須的文本內容，而且不同元素之間相互無重疊冗餘；而方案二存儲的完整檔案除了包含字元格式、字型等信息外，還包含doc檔案必須的檔案格式頭等內容，因此所需空間較大。方案三在方案二的基礎上還冗餘存儲了一些元素內容，因此所需空間最大。但總體看來，方案三與方案二相比，額外所需的存儲空間並不是很大，約占檔案大小的0.5~1%左右。
三種存儲方案下普通查詢的效率和原文檔恢復所需時間分
比較別如圖4、圖5所示。可以看出，方案三普通查詢的效率與方案一幾乎沒有差別，受益於oracle資料庫管理系統的查詢性能，在實驗數據規模上返回結果的時間為毫秒級；而方案二由於需要還原檔案後再進行全文檢索，所需時間較長，尤其隨著資料庫中記錄數增加所需時間也線性增加，當數據規模較大時難以滿足用戶需求。而在文檔恢複方面，方案一需要將所有內容進行重組，並按照公文承辦規定設定相關元素的格式等，所需時間為秒級，而且恢復效果較差；而方案二和方案三直接從資料庫中讀取完整文檔並恢復，所需時間僅為毫秒級。
在採用第三種存儲方案實現的系統中，隨歸檔文檔數的增加，系統自動歸檔所需時間情況如圖6所示。可以看出，系統具有較高的自動分析和批量歸檔功能，平均每個文檔所需的分析歸檔時間不足1秒。因此能夠較好滿足歸檔需求。