許多做數據管理，數據治理的同學，經常會被數據庫（倉庫）中大量繁雜的數據表困擾，很多數據表并不是存儲必要的基礎數據的，而是在計算和查詢中產生的中間表，這些中間表，經過長年累月的積累，往往會達到一個恐怖的數量級，嚴重的影響了數據庫的管理和性能，而且這些中間表，又不敢隨便刪除，因為有的仍然在用，有的不知道還有沒有用，隨意刪除很有可能就會影響業務，這時只能被迫的給數據庫擴容了而這些讓人苦惱的中間表，很大一部分就是因為前端的報表業務所產生的

報表怎么產生的中間表

原始數據量很大時，報表直接基于原始數據計算匯總信息時的性能會很差，用戶體驗惡劣，這時，通常的做法就是先把一些匯總結果事先計算出來，報表再基于這些中間結果做呈現，用戶體驗就會好很多，這些中間數據就會以中間表的形式存儲原始數據到最終呈現的數據計算過程復雜時，一個 SQL 算不完，那就得先把中間結果存一下，然后再繼續算，這就產生了中間表或者很多報表都得基于某個復雜計算的結果來做，每個報表都各自算一次，很繁瑣，還得頻繁占用數據庫資源，那就可以用一個中間表先把結果存下來，供多個報表來用，這也會產生中間表大數據時代，報表的很多數據來源都是來自庫外的，比如文本存儲的數據，或者其他不太好計算的非關系數據源，常用的做法是把庫外數據定時導入到數據庫中，然后就能和數據庫內的數據一起運算了，這就又產生了中間表，而且，有些多層的 json 或 XML 格式，在關系數據庫中還要建立多個關聯的表來存儲，就不是多一個中間表的問題了這些中間表，都是因為報表而產生的

中間表的危害

從上面中間表產生的原因，我們可以看出，它其實是為了解決數據計算本身的難題而誕生的，屬于解決問題的有功之臣，但是當它的數量一旦多起來以后，就把自己也變成了一個難題大量的中間表，會占用很大數據庫容量，甚至有些已經不用的中間表還在定時更新數據，在不斷的變大，那么多表，我們又不知道哪個有用哪個沒用，不敢亂刪，只能放任其不斷的增多、變大，容量告警時，就只能被迫進行數據庫的擴容，而擴容，是需要很大成本的，不管是橫向還是縱向中間表相關的運算還會占用數據庫寶貴的計算資源，影響數據庫的性能，每個中間表都涉及計算，重要的不重要的，有用的沒用的，都在搶資源，量大的時候就會影響數據庫關鍵業務的計算，帶來嚴重的性能問題

怎么解決

中間數據的思路是沒有大問題，有問題的是把它們存到數據庫里這個環節那存到庫外不就可以了嗎？這個想法很好，但之前因為技術限制，存到庫外后會讓續的計算變的復雜，很少有這么做的中間表是要再計算的，基于中間表查詢的報表還要進行數據過濾，有的還要再次匯總，還可能涉及關聯計算，這些操作在數據庫里通過 SQL 完成很簡單，但是文件沒有計算能力，要實施這些計算只能硬編碼，用 JAVA 來做，使用 JAVA 來做集合運算又非常麻煩，遠沒有數據庫（SQL）方便，所以很少有人把中間表存在庫外但現在有新技術了，集成了 SPL 集算器的潤乾報表，讓這種想法變的可行了
SPL 是一款流行的專業的數據計算處理工具，很多項目開發商都在用，因為它不僅好用，而且還免費，開源，是常年做項目，總需要做數據處理的工程師的好幫手集成了 SPL 以后，潤乾報表就有了計算文件數據的能力，這樣數據庫的大量中間表就可以都移到了庫外了，用普通的 TXT 或者其他方式存儲都可以，也可以用 SPL 獨有的更高性能的二進制文件，報表直接可以對接他們來算比如要查詢 2012 年銷售總額超過 800 萬的地區及銷售金額就可以提前匯總數據，并把中間結果用文件存儲的方式存儲，而不需要放到數據庫中

然后報表直接針對文件數據查詢計算就可以

	A
1	=file(“order_year_area_person.txt”).import@t()	// 讀取文件數據（以文本為例）
2	=A1.select(dyear==y_date)	// 根據年份參數過濾數據
3	=A2.groups(area;count(name):pnum,sum(amount):amount)	// 按照地區分組匯總人數和銷售額
4	=A3.select(amount>8000)	// 選出銷售額大于 8000 的記錄

可以用 SPL 的腳本直接計算，如上圖，也可以用 SQL 來計算，如下圖

	A
1	=connect()	// 連接文件系統
2	=A1.query(“select area,count(name) pnum,sum(amount) amount from order_year_area_person.txt where dyear=? group by area having sum(amount)>8000”.y_date)	// 執行標準 SQL 查詢文本

SPL 具有完整的計算能力，高效又簡單，文件存儲數據不好計算的困擾就這么解決了

而且文件存儲還易于管理，性能更好文件存儲易于管理中間結果存到庫外后，數據庫就僅需要存儲少量原始數據表就可以，數據庫自身的管理壓力就會變小，都轉移到了庫外文件上了而庫外的文件，就是普通的計算機文件，天然就便于管理，可以通過系統的樹狀目錄進行存儲，文件都跟著應用走，目錄清晰，使用和管理都很方便，不會出現交叉引用相互耦合的情況，報表棄用或者應用下線，相應的中間存儲文件就可以刪除，再也沒有想刪不敢刪的苦惱了文件存儲性能更好文件系統更靠近底層，更接近磁盤，IO 性能本身就好于數據庫如果用 SPL 的二進制存儲方式，效果會更明顯，因為 SPL 的文件格式更緊湊，對于只讀的中間數據，使用文件存儲時不需要考慮再改寫，可以更為緊致并采用一定的壓縮手段，而且在訪問時也不必考慮事務一致性，機制大為簡化，這樣就能獲得更好的吞吐性能了對于數據量大和計算復雜導致的中間表，可以用文件來解決掉了，而對于多樣性數據源帶來的中間表又該怎么辦呢？也沒問題，SPL 還支持多樣性數據源，可以直接連接各類數據源進行多源混算，不管你存在哪里，有沒有計算能力等，都不需要再把難算的數據導入到關系庫中了形成中間表了

總結

對于報表應用而言，中間數據的存在是有價值的，中間數據的思路也是正確的，但它多起來后的弊端也是顯而易見的，潤乾 SPL 方案并沒有讓中間數據消失，只是把中間表移到了庫外，然后再利用自己的計算能力來完成計算，這樣既能發揮中間數據的價值，又避免了它存到庫內的麻煩，就讓整個中間數據的方案更加完善通暢了。