系統資源綠化_進階查詢篇

[進階查詢]
目前標準操作規範裡都會提供「進階查詢」功能，讓使用者容易找到欲處理之資料。這樣的設計構想是出於好意，但「方便就變成隨便、隨便就會造成大家的不便」。若就整體系統效能考量，使用者一次查出幾千筆上萬筆資料後，而最後只擷取其中的幾筆資料處理是很瘋狂的事情。這像極了一個暴發戶到百貨公司一次買了幾千件衣服回家後，在家裡挑一挑最後只選了幾件其它全部扔掉的感覺一樣，聽起來匪夷所思，但比起目前dejcQryGrid的濫用境況卻真有過之而無不及。
為改善這現象，dejcQryGrid將查詢筆數的限制降到1000，並提供效能耗用統計資料供定期檢討。
類似的效能監控及資源合理性的定期追蹤檢討，日後將擴及其它資源應用方面如 structs 的 action，DB Connection 的資源耗用，DQ的Task使用狀況等。

目前存在之問題主要為兩類:
一) 一次查太多筆資料欲只用其中一兩筆
二) sql 極為複雜，table 與 table 間的 join 關係錯綜複雜，讓系統光完成sql之查詢就耗掉不少cpu資源.

茲針對 dejcQryGrid (進階查詢元件) 將進行的改善作出下列說明:
1 只顯示前面1000筆，超過1000筆時顯示警告訊息「超過上限1000筆」。
2 在執行sql的前後插入計時器，監控每個 sql 的耗用時間、查詢筆數，並針對各sql之使用次數、耗費時間、查詢筆數做統計，每月列出報表檢討各sql執行狀況及資料耗用的合理性。
3 根據第2點，若發現sql耗用時間超過10秒，或查詢筆數超過1萬筆資料時即採取以下措施:
3.1 測試環境: 拋出 exception 警告。
3.2 正式環境: 拋到異常資料表中，每月定時印製報表檢討。
4 目前 dejcQryGrid 計算總筆數做法極耗效能，為改善此問題，將強制AP丟入”count總筆數之sql”。若沒有丟入，測試環境會拋出 exception，正式環境則拋入異常Table，每月定期檢討異常資料。


實作面:
1． 上限筆數透過設定檔設定，可隨時變更。
2． 以上各點所有需拋入異常Table之動作皆以 background方式進行。