上一篇主要介紹了使用jxl生成報表的代碼模板以及獲取報表數據的一種處理方式，本篇將通過兩個復雜報表案例的分析，來告訴大家如何實現。 案例1： 車站區間材料供應情況報表，它的查詢條件為年度，工程，材料類別，報表的標題會加上這些查詢條件作為最終報表標題。無圖無真相，讓我們來看看生成后的效果：
該報表有這樣幾個特點：1)表頭的從5月計量到12月計量是根據查詢條件的年度和工程動態取出來的，因此模板中不會定義6-13列。2)數據顯示上有好幾個分類，首先按供貨商分，每個供貨商下面，再按月根據實際的供貨數量再進行劃分。3)需要對每個供貨商每個月的材料進行小計，如果有多個供貨月，還要將本月與之前月的供貨數量進行合計。
這是大象2008年做的一個工程項目，是該項目中比較有代表性的一個報表，所有與工程相關的項目在業務上還是比較相似的，因為它有一套非常成熟的標準與規范。至于這些業務數據的表設計是什么樣的，大家不需要了解，我主要根據它的業務特點來說說思路。 我將這個報表進行分解，看看到底要準備什么數據，特別注意這些數據是和年度，工程，材料類別這些查詢條件緊密關聯的。PS：甲供材料與甲控材料都是工程上的名詞，不寫清楚會對了解該行業的人產生誤解。 1、表頭的計量月份。 2、甲供材料供應商信息。 3、甲供材料供應月份(第2列)。
4、甲供材料數據(第3-5列)。 5、甲供材料每個月的計量值(與表頭的計量月份對應)。 6、每月的小計和合計。
處理這類復雜報表，首先需要搞清楚它的業務關系，這個非常關鍵，如果你連這些業務都沒弄明白就開始動手做，最后肯定是會有問題的。只有在明白這些關聯關系之后，我們才能接著做第二步工作，分解數據，研究數據來源，比如我上面寫的1-6點，這些業務數據都分別在哪些表里面，哪些是可以直接取到的，哪些又必須是要經過計算才能得到的。比如那個剩余數量，小計，合計這些明顯都是在基礎數據上計算出來的。要清楚的知道，每個Cell里面是不是有內容，并且內容來源是不是正確的？就算你對自己非常有信心，還是請多核對檢查，認真對待工作是不會有錯的。
前兩步的思想是比較通用的，但第三步，也就是最重要也是最麻煩的獲取數據，我不想針對案例報表說具體的步驟，那樣就太狹隘了。這一步的解決辦法有很多，我在第一篇里也曾經提到過，不管是代碼式還是SQL式還是分而治之式，總之要盡可能的減少數據庫訪問次數。看到這里，可能有人要吐槽了，這不是說了跟沒說一樣嗎？大象根據多年的經驗，很真誠很真誠的告訴你，如果你能夠做好第一步和第二步工作，那么你離完成報表也差不了多少了，其實第三步只是需要一些編程能力與SQL能力，以及在運用這些能力之前結合業務與報表的數據做一些優化方面的工作。永遠記住，盡可能的減少訪問數據庫次數。 最后一步當然是生成報表了，這里我想多說一句，報表的樣式一般都是客戶給的，因為在用系統導出報表前，肯定是先手動做的，因此樣式上一定要跟用戶的保持一致，這些東西最后客戶那里會歸檔，領導也會看還要簽字，作批示什么的。就像案例1的報表，它的樣式就是完全按照客戶給的來設定。 在寫填充數據的代碼之前，先確保表頭已經沒問題，像案例1這種動態表頭就必須要用代碼來實現，在模板中是不可能預先定義好的。然后就是你所準備的數據模型是否能夠幫助你處理邏輯上的一些控制。比如像供應商填充，小計，合計，還有普通數據，要讓for循環里面的代碼知道，每循環一次，相應的數據應該出現在哪些單元格中，你需要時刻計算一下當前數據與所對應的Cell是否一致。最后就是注意一些常識性的細節，比如上面留空白的地方，對于12月份供應的材料來說，它之前的月份是肯定不會有使用記錄的，如果最后生成的報表中，像這類位置出現了數值，那你就要好好檢查一下了，這里留白也是因為客戶的報表是這樣做的。
案例2： xx市城建局工程招標結果匯總表，查詢條件為工程編號，工程名稱，工程科室。大標題可以預先填好，但第2行用xxx標示的內容就是動態修改的，而且報表最終打印出來后是要給領導簽字的，這就是明顯的要按用戶格式來。 
這個報表來自于2009年的一個項目，相比第1個我認為要簡單一些，從業務上講，就是工程項目的招投標流程的歸納與體現。可以把數據分解為： 1、工程項目信息(工程編號與工程名稱)。 2、招投標信息(分中標和流標再中標兩種)。 3、合同信息(合同簽訂時間，原報表還有好幾列關于合同的數據，如果都保留圖顯得太大了)。 這個報表的處理步驟和前一個一樣，就不再贅述了。需要注意的是，在準備數據的時候，想想類似工程編號與工程名稱這種Cell，如何知道要合并幾行單元格(或者不合并)。完成之后多找些有效數據來測試。 另外我還想談下查詢條件，比如案例1中的年度、工程、材料類別，案例2的工程編號，工程名稱，工程科室。因為查詢條件的多少以及對條件的限制情況會直接影響到報表數據的獲取。這些東西是可以和客戶溝通的，千萬不要把客戶的訴求當需求，他們因為不懂開發，只從業務的角度考慮問題，而且很多時候提出的要求是直接拍腦袋說的，他們要么希望大而全，恨不得把報表里面所有的列都作為查詢條件；要么希望少而精，很少條件或不要查詢條件。不管哪一個都不是我們希望的，這時候需要多溝通，在需求與系統之間找到一個平衡。 感謝大家耐著性子看到這里，期望通過這兩篇文章的介紹，能夠對大家有所幫助，對于開發復雜報表起到一個拋磚引玉的作用。如果大象有說的不對的地方，還請各位指出來，在下感激不盡！ 本文為菠蘿大象原創，如要轉載請注明出處。http://www.aygfsteel.com/bolo
posted on 2014-01-09 14:16
菠蘿大象 閱讀(2693)
評論(0) 編輯 收藏 所屬分類:
Java