複雜報表設計

2021-05-23 00:06:05 字數 2831 閱讀 4306

【it168 專稿】

報表無疑是erp系統中用到的最頻繁的單據之一。比如每天採購要列印採購明細帳;倉庫每天要匯出收貨或者出貨明細;銷售每天要列印訂單明細等。故報表的設計在erp系統開發中佔據大半江山。不過筆者在實際工作中也發現,有些開發人員在設計erp報表時,太過於複雜。

有一次,一家企業向我提出了如下需求:他們希望能夠出乙份報表,報表的內容包括四個部分。一是成品零件的用量、零件的最小採購量等資訊;二是當月零件的採購量資訊(詳細的採購訂單等資料);三是當月零件的出庫資訊(詳細的出貨記錄);四是零件的安全庫存資訊。然後,根據這些資訊計算出當月需要補下的滿足安全庫存的數量。從這個需求中可以看出,其主要設計到產品基本資料、採購、倉庫等三個模組的內容。這麼複雜的報表,從技術上來說,實現的難度並不是很大。但是從實用性角度考慮,或者從準確性來看,又會有什麼結果呢?

一、報表越複雜,準確性越難以把握

一般來說,報表越複雜,其準確性余越難以把握。其實拋開erp系統,從統計學的角度,我們也可以得出這個結論。如下圖所示,現在有三個抽屜。每個抽屜中都有0-9十個數字。如果現在從每個抽屜中隨意抽出兩個數字,最後組成乙個三位數。那麼最後有幾種結構呢?這是乙個排列組合的問題。

抽屜1抽屜2

抽屜3

再回過頭來看一下這個表單的內容。現在這個表單有三個模組的資料構成。就好像這三個抽屜。當然其抽屜中的資料遠比10個數字要負載的多。我們設想一下,從單個模組來看。可能企業允許的誤差率是5%。即100條記錄中,允許有5條記錄與實際有偏差。現在三部分資訊共同組成的一張報表,而且最後需要根據三部分資訊的內容計算出乙個值,那麼這個出現錯誤的記錄會有多少呢?這又是乙個排列組合的問題。如假設每部分資訊中,都有5條件有偏差,那麼最後理論上的錯誤記錄是125條。顯然這個錯誤率比較大。同時也可以看出,當涉及到的基礎表數量越多,涉及到的模組越多,其最後結果的準確性就越難以保障。而當資料的準確性不高時,其實用性也就相應的降低。

二、報表關聯越多,其效能也會直線下降

報表越複雜,其涉及到的後台資料庫基礎表也就越多。雖然多表之間的關聯查詢是允許的,但是關聯的關鍵字越多,其查詢的效率也就越低。特別是在關聯條件中,有時候採用的並不是關鍵字之間的關聯。如有可能日期(字元資料型別的關聯)之間的關聯,此時查詢的效率會更低。再加上比較複雜的where邏輯判斷語句,複雜報表的查詢時間會很長。如筆者測試過,按照上面這個使用者的需求,設計出的報表其查詢的時間需要近三分鐘,而且是已經優化過的查詢。另外,這個報表的查詢由於涉及到眾多的基礎表,資料庫基本上需要訪問硬碟

上的資料檔案,而不能夠使用快取。這就有可能會導致比較嚴重的硬碟

i/o衝突。從而影響到其它資料的查詢效率。

故從資料庫與應用軟體的整體效能考慮,也不建議採用比較複雜的報表檢視。畢竟效能降低、查詢的時間比較長時,報表的實用性也在降低。

三、設計複雜報表的注意事項

為此,從原則上是禁止設計超過兩個模組的資料包表,最好是將報表的範圍限制在單個模組下。如此的話,無論從效能還是從資料的準確性上都會有所保障。但是,如果使用者確實有需要實現比較複雜的報表,在這種情況下,該如何處理呢?為此筆者根據自己的專案經驗,提出了以下幾個建議。

一,是可以使用固化檢視來改善資料庫的效能。複雜報表所導致的不利影響,其首當其衝的是報表查詢時速度會很慢,效能很低。為此在涉及到複雜報表時,開發人員可以考慮採用固化檢視來改善資料庫的效能。如在oracle資料庫中,固化檢視又叫做物化檢視。通固化檢視,可以用於預先計算並儲存表連線或者聚集等耗時比較多的操作結果。簡單的說,就將某個報表的查詢結果儲存在一張單獨的表中。如此的話,在執行查詢時,就可以避免使用這些耗時的操作,同時減少磁碟的i/o衝突,從而以最短的時間得到使用者想要的結果。一般來說,固化檢視對於複雜的報表來說,能夠提供三方面的作用。如可以提高查詢的效能。如固化檢視對於應用來說是透明的,增加和刪除物化檢視不會影響應用程式中sql語句的正確性和有效性。如當基表發生變化時,物化檢視也會同時更新。不過需要注意的是,物化檢視也會帶來一些負面影響。如物化檢視的資料會儲存在硬碟

中,為此就會占用額外的儲存空間等。總之,在設計比較複雜的報表時,開發人員可以與資料庫工程師商量,能夠採用固化檢視。如果可以的話,需要盡量採用固化檢視。

二,是複雜的報表當設計到多表時,最好採用模組化的設計。如上面這個檢視,其涉及到的基表有近20張。那麼在設計檢視時,要避免將其放在乙個sql語句中。而應該借鑑應用程式的模組化設計,將其設計成不同層次的檢視,然後再進行連線查詢。如上面這個案例,至少可以將其分為四層。最基層是基本資料表,第二層是零件出庫資訊、當月採購資訊等資料,第三層是根據第二層的資料進行計算分析;第三層檢視再將這些檢視進行連線。這麼操作的話,方便後續的維護與查詢。同時也可以提高查詢的速度。為什麼這麼說呢?如在第二層檢視設計中,可以對基礎表的資料進行過濾。此時由於基礎資料少,那麼後續的報表查詢速度也會加快。為此對於比較複雜報表的設計,要考慮分層設計的思路。以提高報表的查詢效能與靈活性。

三,是要考慮資料核對的需要。比較複雜的報表,其可能會涉及到多個不同的部門。如上面個報表,其涉及到倉庫、採購、銷售、開發等多個部門。而且最後的計算結果需要根據這些部門的資訊得出。為此為了提高資料的準確性,就需要多個部分進行積極的配合。那麼該如何來做到這一點呢?筆者認為,可以將這些檢視分模組化設計。如將涉及到不同的部門的資訊先設計成不同的報表。在某個特定的時刻,如月末,先讓各個部門的人員核對相關的資料。核對完成沒有錯誤之後,再對相關的資料進行運算。而不是一開始就將所有資料在一張報表上顯示。這會導致各個部門資料核對的麻煩,即各個部門不利於核對與自己相關的資料。其實這一點跟上面提到的檢視分層化設計類似。在erp上,報表的內容也要分不同的模組進行體現。這有利於使用者對資料進行核對與確認。然後再將它們整合起來。這種各個擊破的方式,就有利於提高資料的準確性。

可見,對於比較複雜的報表檢視,原則上還是少見為妙。因為其在效能或者資料的準確性上都很難控制。如果真的要建立複雜檢視的時候,那麼在設計與開發時,顧問需要聽取資料庫工程師的意見,考慮如何提高資料的查詢效能,並採取措施提高資料的準確性。

動態列 模板 複雜報表設計之動態報表

如上圖所示,可以需選擇不同的分組維度進行資料分析,例如類別 商維度 可以通過使用者輸入的引數值進行資料動態過濾,例如傳入不同 商 類別的值進行資料查詢過濾 可以選擇要顯示的附加字段資料 同時要求顯示有排名 每個分組內的資料從大到小顯示 佔比 產品占該分組維度總訂購量的百分比 此示例使用指令碼資料集完...

動態列 模板 複雜報表設計之動態報表

如上圖所示,可以需選擇不同的分組維度進行資料分析,例如類別 商維度 可以通過使用者輸入的引數值進行資料動態過濾,例如傳入不同 商 類別的值進行資料查詢過濾 可以選擇要顯示的附加字段資料 同時要求顯示有排名 每個分組內的資料從大到小顯示 佔比 產品占該分組維度總訂購量的百分比 此示例使用指令碼資料集完...

Flex報表 ibizGrid 複雜報表

先介紹下flex第三方的報表元件。mecgrid mecgrid是乙個開放api但不開放源 的免費報表元件。它的官方位址是 它 具體特性如下所示 但是,mecgrid缺點還是挺多的。2 nec grid 日本人做的報表元件,功能還是挺強大的,但是是收費的。這個 介紹了nec grid元件的使用方法 ...