項目報表開發

通常狀況下，項目的報表都是在最後階段開發，由於在軟件開發過程中，可能需求或者軟件的數據庫設計等會發生一些變化和改動，若是提早開發報表，則會形成後期報表的不停的修改.修改..修改!

目前項目也接近收尾，正式集中全力開發報表，處理bug的時間段。咱們項目中，合做方採用的是深圳明宇科技的如意報表。之前也看過這個報表開發工具，可是沒有詳細的瞭解過。從目前的狀況來看，我我的認爲是本項目的報表狀況很是不理想。

首先，基於合做方框架要求來考慮，他們把報表設計成爲一個頁面來顯示全部的報表。普通狀況下，咱們都是採用菜單來顯示報表的名字，一個報表一個名字。點擊相應的菜單就進入報表進行查詢。

而咱們開發方採用的方式不是這樣的，菜單隻有一個，就是「查看報表」，點擊進入以後，就是報表的列表頁面，經過點擊列表頁面的查看連接來打開報表。這個列表頁面很是難看，給人的感受很混亂，並且若是報表一多，就須要點擊下一頁查看或者先查詢到具體的報表再點擊，操做起來也很不方便。我不知道爲何他們要這麼設計，總之很是的爛！ 

其次，報表的條件頁面沒法設置默認條件。目前的報表條件頁面，爲了減小工做量，設計方案是：把各個報表的條件，直接寫入數據庫表中，條件頁面，經過報表的ID來查找相應的報表的查詢條件，而後經過一個統一的程序處理，把它顯示出來。

沒法評估這種作法的優缺點，咱們之前的作法是，一個條件頁面就是一個程序，好比asp或者jsp等等，感受他的方案仍是有優點的。可是問題是，目前的條件頁面出來以後，沒法爲各個條件設置默認值。好比，查詢條件的年月，咱們要求默認爲當前年月，對方項目經理的說法是，這樣作，他們目前的處理程序難度太大，工做量很大，要一個一個報表的修改；結論是：不修改。這個給用戶的體驗很是差。目前這一點正在溝通中，項目中就是這樣，老是要不停的溝通，爭取！一個默認條件都要去溝通爭取，這也是爲何這個項目作的累的緣由。

我之前一個同事，離職後去了一個外包項目的公司。他說他們公司的項目，若是是簽字以前就提出來的需求，就必定要知足，哪怕是把底層代碼重寫一遍都要完成。可是對於客戶之前沒有提出來的東西，都是不考慮的，除非從新簽定新需求的合同。遺憾的是，啥時候咱們才能碰到這麼樣的乙方呢？更遺憾的是，啥時候咱們的人才能變成這種甲方呢？

若是是在其它的項目中，我可能會說，這是甲方需求變更形成的，可是在這個項目中，我只會認爲這是乙方的緣由形成的。緣由我會在之後的日記中說明。

第三，複雜報表的展示方式很困難。關於這一點，我不知道是否是與如意報表有關係。由於咱們系統中涉及到財務相關的內容，爲了方便財務對帳等操做，報表設計的比較複雜，報表中間設計了不少的合計小計。合做方就反映說實現起來難度很大。另外，兩維的報表實現起來難度也很大，而且今天一個開發人員反映說，兩維的報表若是報表上要同時顯示備件和備件編碼就不行。我都不知道爲何？到如今都沒有搞清楚

從我看他們的代碼理解他們的設計意圖來看，估計跟他們的報表設計方案有關係。他們採用的是經過存儲過程的遊標直接顯示的方式展現報表。固然，咱們設計的報表複雜度也有關係。

第四，我如今擔憂的是，報表的性能問題，由於他們不少的報表都是經過存儲過程直接多表關聯直接訪問來查詢並顯示數據的。而咱們之前的報表，都是先經過晚上定時運行的數據庫job來統計數據到中間表，基本上中間表基本上和要顯示的報表樣式很相近了。報表的顯示過程就直接讀取中間表的數據，簡單處理一下，作一下彙總就能夠了。這種方式的缺點就是，當天只能查詢前一天的數據。可是性能會好不少，避開業務高峯時期來充分使用數據庫的資源。

其它問題，之後再說!