報(bào)表無疑是ERP系統(tǒng)中用到的最頻繁的單據(jù)之一。比如每天采購要打印采購明細(xì)帳；倉庫每天要導(dǎo)出收貨或者出貨明細(xì)；銷售每天要打印訂單明細(xì)等。故報(bào)表的設(shè)計(jì)在ERP系統(tǒng)開發(fā)中占據(jù)大半江山。不過筆者在實(shí)際工作中也發(fā)現(xiàn)，有些開發(fā)人員在設(shè)計(jì)ERP報(bào)表時(shí)，太過于復(fù)雜。

　　有一次，一家企業(yè)向我提出了如下需求：他們希望能夠出一份報(bào)表，報(bào)表的內(nèi)容包括四個(gè)部分。一是成品零件的用量、零件的最小采購量等信息；二是當(dāng)月零件的采購量信息（詳細(xì)的采購訂單等資料）；三是當(dāng)月零件的出庫信息（詳細(xì)的出貨記錄）；四是零件的安全庫存信息。然后，根據(jù)這些信息計(jì)算出當(dāng)月需要補(bǔ)下的滿足安全庫存的數(shù)量。從這個(gè)需求中可以看出，其主要設(shè)計(jì)到產(chǎn)品基本資料、采購、倉庫等三個(gè)模塊的內(nèi)容。這么復(fù)雜的報(bào)表，從技術(shù)上來說，實(shí)現(xiàn)的難度并不是很大。但是從實(shí)用性角度考慮，或者從準(zhǔn)確性來看，又會(huì)有什么結(jié)果呢？

　　一、報(bào)表越復(fù)雜，準(zhǔn)確性越難以把握

　　一般來說，報(bào)表越復(fù)雜，其準(zhǔn)確性余越難以把握。其實(shí)拋開ERP系統(tǒng)，從統(tǒng)計(jì)學(xué)的角度，我們也可以得出這個(gè)結(jié)論。如下圖所示，現(xiàn)在有三個(gè)抽屜。每個(gè)抽屜中都有0-9十個(gè)數(shù)字。如果現(xiàn)在從每個(gè)抽屜中隨意抽出兩個(gè)數(shù)字，最后組成一個(gè)三位數(shù)。那么最后有幾種結(jié)構(gòu)呢？這是一個(gè)排列組合的問題。

　　再回過頭來看一下這個(gè)表單的內(nèi)容?，F(xiàn)在這個(gè)表單有三個(gè)模塊的數(shù)據(jù)構(gòu)成。就好像這三個(gè)抽屜。當(dāng)然其抽屜中的數(shù)據(jù)遠(yuǎn)比10個(gè)數(shù)字要負(fù)載的多。我們?cè)O(shè)想一下，從單個(gè)模塊來看?？赡芷髽I(yè)允許的誤差率是5%。即100條記錄中，允許有5條記錄與實(shí)際有偏差?，F(xiàn)在三部分信息共同組成的一張報(bào)表，而且最后需要根據(jù)三部分信息的內(nèi)容計(jì)算出一個(gè)值，那么這個(gè)出現(xiàn)錯(cuò)誤的記錄會(huì)有多少呢？這又是一個(gè)排列組合的問題。如假設(shè)每部分信息中，都有5條件有偏差，那么最后理論上的錯(cuò)誤記錄是125條。顯然這個(gè)錯(cuò)誤率比較大。同時(shí)也可以看出，當(dāng)涉及到的基礎(chǔ)表數(shù)量越多，涉及到的模塊越多，其最后結(jié)果的準(zhǔn)確性就越難以保障。而當(dāng)數(shù)據(jù)的準(zhǔn)確性不高時(shí)，其實(shí)用性也就相應(yīng)的降低。

　　二、報(bào)表關(guān)聯(lián)越多，其性能也會(huì)直線下降

　　報(bào)表越復(fù)雜，其涉及到的后臺(tái)數(shù)據(jù)庫基礎(chǔ)表也就越多。雖然多表之間的關(guān)聯(lián)查詢是允許的，但是關(guān)聯(lián)的關(guān)鍵字越多，其查詢的效率也就越低。特別是在關(guān)聯(lián)條件中，有時(shí)候采用的并不是關(guān)鍵字之間的關(guān)聯(lián)。如有可能日期（字符數(shù)據(jù)類型的關(guān)聯(lián)）之間的關(guān)聯(lián)，此時(shí)查詢的效率會(huì)更低。再加上比較復(fù)雜的Where邏輯判斷語句，復(fù)雜報(bào)表的查詢時(shí)間會(huì)很長。如筆者測試過，按照上面這個(gè)用戶的需求，設(shè)計(jì)出的報(bào)表其查詢的時(shí)間需要近三分鐘，而且是已經(jīng)優(yōu)化過的查詢。另外，這個(gè)報(bào)表的查詢由于涉及到眾多的基礎(chǔ)表，數(shù)據(jù)庫基本上需要訪問硬盤上的數(shù)據(jù)文件，而不能夠使用緩存。這就有可能會(huì)導(dǎo)致比較嚴(yán)重的硬盤I/O沖突。從而影響到其它數(shù)據(jù)的查詢效率。

　　故從數(shù)據(jù)庫與應(yīng)用軟件的整體性能考慮，也不建議采用比較復(fù)雜的報(bào)表視圖。畢竟性能降低、查詢的時(shí)間比較長時(shí)，報(bào)表的實(shí)用性也在降低。

　　三、設(shè)計(jì)復(fù)雜報(bào)表的注意事項(xiàng)

　　為此，從原則上是禁止設(shè)計(jì)超過兩個(gè)模塊的數(shù)據(jù)報(bào)表，最好是將報(bào)表的范圍限制在單個(gè)模塊下。如此的話，無論從性能還是從數(shù)據(jù)的準(zhǔn)確性上都會(huì)有所保障。但是，如果用戶確實(shí)有需要實(shí)現(xiàn)比較復(fù)雜的報(bào)表，在這種情況下，該如何處理呢？為此筆者根據(jù)自己的項(xiàng)目經(jīng)驗(yàn)，提出了以下幾個(gè)建議。

　　一、是可以使用固化視圖來改善數(shù)據(jù)庫的性能。復(fù)雜報(bào)表所導(dǎo)致的不利影響，其首當(dāng)其沖的是報(bào)表查詢時(shí)速度會(huì)很慢，性能很低。為此在涉及到復(fù)雜報(bào)表時(shí)，開發(fā)人員可以考慮采用固化視圖來改善數(shù)據(jù)庫的性能。如在Oracle數(shù)據(jù)庫中，固化視圖又叫做物化視圖。通固化視圖，可以用于預(yù)先計(jì)算并保存表連接或者聚集等耗時(shí)比較多的操作結(jié)果。簡單的說，就將某個(gè)報(bào)表的查詢結(jié)果存儲(chǔ)在一張單獨(dú)的表中。如此的話，在執(zhí)行查詢時(shí)，就可以避免使用這些耗時(shí)的操作，同時(shí)減少磁盤的I/O沖突，從而以最短的時(shí)間得到用戶想要的結(jié)果。一般來說，固化視圖對(duì)于復(fù)雜的報(bào)表來說，能夠提供三方面的作用。如可以提高查詢的性能。如固化視圖對(duì)于應(yīng)用來說是透明的，增加和刪除物化視圖不會(huì)影響應(yīng)用程序中SQL語句的正確性和有效性。如當(dāng)基表發(fā)生變化時(shí)，物化視圖也會(huì)同時(shí)更新。不過需要注意的是，物化視圖也會(huì)帶來一些負(fù)面影響。如物化視圖的數(shù)據(jù)會(huì)保存在硬盤中，為此就會(huì)占用額外的存儲(chǔ)空間等?？傊谠O(shè)計(jì)比較復(fù)雜的報(bào)表時(shí)，開發(fā)人員可以與數(shù)據(jù)庫工程師商量，能夠采用固化視圖。如果可以的話，需要盡量采用固化視圖。

　　二、是復(fù)雜的報(bào)表當(dāng)設(shè)計(jì)到多表時(shí)，最好采用模塊化的設(shè)計(jì)。如上面這個(gè)視圖，其涉及到的基表有近20張。那么在設(shè)計(jì)視圖時(shí)，要避免將其放在一個(gè)SQL語句中。而應(yīng)該借鑒應(yīng)用程序的模塊化設(shè)計(jì)，將其設(shè)計(jì)成不同層次的視圖，然后再進(jìn)行連接查詢。如上面這個(gè)案例，至少可以將其分為四層。最基層是基本數(shù)據(jù)表，第二層是零件出庫信息、當(dāng)月采購信息等數(shù)據(jù)，第三層是根據(jù)第二層的數(shù)據(jù)進(jìn)行計(jì)算分析；第三層視圖再將這些視圖進(jìn)行連接。這么操作的話，方便后續(xù)的維護(hù)與查詢。同時(shí)也可以提高查詢的速度。為什么這么說呢？如在第二層視圖設(shè)計(jì)中，可以對(duì)基礎(chǔ)表的數(shù)據(jù)進(jìn)行過濾。此時(shí)由于基礎(chǔ)數(shù)據(jù)少，那么后續(xù)的報(bào)表查詢速度也會(huì)加快。為此對(duì)于比較復(fù)雜報(bào)表的設(shè)計(jì)，要考慮分層設(shè)計(jì)的思路。以提高報(bào)表的查詢性能與靈活性。

　　三、是要考慮數(shù)據(jù)核對(duì)的需要。比較復(fù)雜的報(bào)表，其可能會(huì)涉及到多個(gè)不同的部門。如上面?zhèn)€報(bào)表，其涉及到倉庫、采購、銷售、開發(fā)等多個(gè)部門。而且最后的計(jì)算結(jié)果需要根據(jù)這些部門的信息得出。為此為了提高數(shù)據(jù)的準(zhǔn)確性，就需要多個(gè)部分進(jìn)行積極的配合。那么該如何來做到這一點(diǎn)呢？筆者認(rèn)為，可以將這些視圖分模塊化設(shè)計(jì)。如將涉及到不同的部門的信息先設(shè)計(jì)成不同的報(bào)表。在某個(gè)特定的時(shí)刻，如月末，先讓各個(gè)部門的人員核對(duì)相關(guān)的數(shù)據(jù)。核對(duì)完成沒有錯(cuò)誤之后，再對(duì)相關(guān)的數(shù)據(jù)進(jìn)行運(yùn)算。而不是一開始就將所有數(shù)據(jù)在一張報(bào)表上顯示。這會(huì)導(dǎo)致各個(gè)部門數(shù)據(jù)核對(duì)的麻煩，即各個(gè)部門不利于核對(duì)與自己相關(guān)的數(shù)據(jù)。其實(shí)這一點(diǎn)跟上面提到的視圖分層化設(shè)計(jì)類似。在ERP上，報(bào)表的內(nèi)容也要分不同的模塊進(jìn)行體現(xiàn)。這有利于用戶對(duì)數(shù)據(jù)進(jìn)行核對(duì)與確認(rèn)。然后再將它們整合起來。這種各個(gè)擊破的方式，就有利于提高數(shù)據(jù)的準(zhǔn)確性。

　　可見，對(duì)于比較復(fù)雜的報(bào)表視圖，原則上還是少見為妙。因?yàn)槠湓谛阅芑蛘邤?shù)據(jù)的準(zhǔn)確性上都很難控制。如果真的要建立復(fù)雜視圖的時(shí)候，那么在設(shè)計(jì)與開發(fā)時(shí)，顧問需要聽取數(shù)據(jù)庫工程師的意見，考慮如何提高數(shù)據(jù)的查詢性能，并采取措施提高數(shù)據(jù)的準(zhǔn)確性。