在數(shù)據(jù)庫中有一類用于保存中間計算結(jié)果的物理表，通常被稱為“中間表”。中間表主要跟 OLAP（在線聯(lián)機分析）業(yè)務(wù)有關(guān)，產(chǎn)生的原因主要有以下幾方面。

中間表來源1. 計算邏輯復(fù)雜
在 OLAP（報表或查詢）業(yè)務(wù)中，有些計算邏輯很復(fù)雜，每次都從頭寫會導(dǎo)致報表開發(fā)過于繁瑣，而且有的計算用 SQL 很難寫出來。這時會采用中間表事先計算好，再基于預(yù)計算的中間結(jié)果開發(fā)報表。
計算邏輯復(fù)雜常見于報表業(yè)務(wù)中，以固定報表最為常見；多維分析則比較少見。2. 查詢性能差
當(dāng)查詢涉及的數(shù)據(jù)量很大或者計算邏輯很復(fù)雜時查詢性能會很差。為了提升查詢性能，增強用戶體驗，通常會把匯總結(jié)果實現(xiàn)計算出來存儲在中間表中。基于預(yù)匯總的中間表查詢速度會快很多。
在實際業(yè)務(wù)中，大部分提升查詢速度的中間表也都是為報表服務(wù)的。3.ETL 過程轉(zhuǎn)存
ETL 過程也會產(chǎn)生中間表。ETL 過程中常常會涉及到數(shù)據(jù)庫的數(shù)據(jù)，正常的 ETL 過程應(yīng)當(dāng)是 E、T、L 這三個步驟逐步進行，也就是先清洗轉(zhuǎn)換之后再加載進數(shù)據(jù)庫，最后在數(shù)據(jù)庫中的只是合理的結(jié)果數(shù)據(jù)。但是，E（清洗）和 T（轉(zhuǎn)換）這兩個步驟中會涉及到大量數(shù)據(jù)計算，而在數(shù)據(jù)庫外實施這些計算很不方便，所以實際情況就會是把涉及到的所有數(shù)據(jù)都先加載進來然后再進行清洗和轉(zhuǎn)換，ETL 過程變成了 ELT 甚至 LET。事先要加載的這些數(shù)據(jù)在關(guān)系數(shù)據(jù)庫中也必須以表的形式存儲，這就使數(shù)據(jù)庫中增加了許多并非最終需要的中間表。
如果觀察一下這些跑批任務(wù)，你會發(fā)現(xiàn) ETL 任務(wù)很多都是為報表業(yè)務(wù)服務(wù)的。4. 多樣性數(shù)據(jù)源混合計算
另一種情況是多樣性數(shù)據(jù)源造成的，這也是為數(shù)據(jù)呈現(xiàn)（報表查詢）服務(wù)的。現(xiàn)代應(yīng)用中的數(shù)據(jù)呈現(xiàn)經(jīng)常會涉及數(shù)據(jù)庫外的數(shù)據(jù)，目前一般的做法是把庫外數(shù)據(jù)定時導(dǎo)入到數(shù)據(jù)庫中，然后就能和數(shù)據(jù)庫內(nèi)的數(shù)據(jù)一起運算產(chǎn)生報表，否則很難實現(xiàn)數(shù)據(jù)庫內(nèi)外的數(shù)據(jù)的混合運算。這當(dāng)然也會讓數(shù)據(jù)庫中多了一些表，而且，有些互聯(lián)網(wǎng)上取過來的數(shù)據(jù)常常是多層的 json 或 XML 格式，在關(guān)系數(shù)據(jù)庫中還要建立多個關(guān)聯(lián)的表來存儲，會進一步加劇中間表過多的問題。
通過列舉的 4 個中間表產(chǎn)生的主要原因，我們發(fā)現(xiàn)一個共同點：中間表大部分情況都是為報表服務(wù)的。我們也知道，實際業(yè)務(wù)中的報表數(shù)量非常多，而且報表業(yè)務(wù)業(yè)務(wù)不穩(wěn)定經(jīng)常會新增修改報表，這會導(dǎo)致中間表數(shù)量不斷增多。
中間表會帶來哪些問題
中間表是一把雙刃劍，提供很多便利的同時也會帶來一些問題。
我們曾在一個運營商的報表系統(tǒng)中，發(fā)現(xiàn)了一個讓人吃驚的現(xiàn)象。在 DB2 數(shù)據(jù)倉庫中，有兩萬多個數(shù)據(jù)庫表！經(jīng)過深入了解發(fā)現(xiàn)，真正的原始數(shù)據(jù)表只有幾百張，剩下的大量的數(shù)據(jù)庫表都是為查詢和報表服務(wù)的中間表。
像這種系統(tǒng)經(jīng)過幾年乃至十幾年的運行，數(shù)據(jù)庫中的中間表越來越多，甚至出現(xiàn)這種上萬個的情況并不少見。大量中間表帶來的直接困擾是數(shù)據(jù)庫存儲空間不夠用，面臨頻繁的擴容需求。中間表對應(yīng)的存儲過程、觸發(fā)器等等需要占用數(shù)據(jù)庫的計算資源，也會造成數(shù)據(jù)庫的擴容壓力。
中間表過多還會帶來管理方面的問題，對于成千上萬張中間表想要梳理清楚恐怕是一件非常頭疼的事情。
那么，是不是可以清理掉一些不用的中間表？一般的結(jié)論都是：搞不動。數(shù)據(jù)庫中的中間表是不同程序員制作的，有的是綜合查詢系統(tǒng)使用，有的是報表系統(tǒng)使用。中間表之間還存在交叉引用，有些程序員看到有別人生成的中間表就直接使用了。有時候一些查詢報表已經(jīng)廢棄不用了，但是對應(yīng)的中間表沒人敢刪，因為不知道刪掉之后會影響其他什么查詢或者報表。
很多情況下，項目組只好為了越來越多的中間表去擴容數(shù)據(jù)庫。但是數(shù)據(jù)庫的擴容成本太昂貴了：不管是換更強的服務(wù)器（縱向擴容），還是增加數(shù)據(jù)庫服務(wù)器的節(jié)點（橫向擴容），都不便宜。
總結(jié)來說，中間表會帶來管理、容量和性能三方面的問題。
如何解決中間表的問題？
可以很容易想到的方式是使用庫外文件存儲中間表數(shù)據(jù)，這樣中間表脫離了數(shù)據(jù)庫就不會對數(shù)據(jù)庫再產(chǎn)生影響。但是，在實際應(yīng)用中這種辦法卻很少使用。為什么呢？
我們知道，中間表是要再計算的，基于中間表查詢的報表還要進行數(shù)據(jù)過濾，有的還要再次匯總，還可能涉及關(guān)聯(lián)計算，這些操作在數(shù)據(jù)庫里通過 SQL 完成很簡單。但是文件沒有計算能力，要實施這些計算只能硬編碼，用 JAVA 來做，使用 JAVA 來做集合運算又非常麻煩，遠(yuǎn)沒有數(shù)據(jù)庫（SQL）方便。所以采用文件存儲中間表的方式使用并不廣泛，主要是由實現(xiàn)復(fù)雜度過高導(dǎo)致的。
那還有什么好的方式呢？使用支持文件源的報表工具
既然中間表大部分是為報表服務(wù)的，而通過將中間表外置到文件中可以解決中間表帶來的這些問題，那么直接使用支持文件源的報表工具是否就可以了呢？
答案是肯定的。
我們來看一下要實現(xiàn)這個目標(biāo)，報表工具要具備哪些能力？(1) 豐富的計算類庫
要解決文本計算難的問題，報表工具要提供豐富的計算類庫，除了能完成所有數(shù)據(jù)處理任務(wù)（都能算）以外，還要實現(xiàn)簡單，這是基礎(chǔ)，太復(fù)雜了沒法用；(2) 多樣性數(shù)據(jù)源接口
支持多樣性數(shù)據(jù)源以后，就可以不用通過數(shù)據(jù)庫中轉(zhuǎn)直接讀取多樣性數(shù)據(jù)源數(shù)據(jù)出報表；(3) 異構(gòu)數(shù)據(jù)源混合計算能力
提供多樣性數(shù)據(jù)源接口后，還要能夠進行異構(gòu)源間的混合計算，這樣就可以徹底解決掉多樣性數(shù)據(jù)源帶來的中間表問題；(4) 高性能
除了實現(xiàn)簡單以外，計算性能也要有保障，從而滿足前端報表查詢的性能需要。
具體實現(xiàn)上可以在報表工具中增加計算模塊來對接“庫外中間表”，結(jié)構(gòu)類似這樣

其中庫外中間數(shù)據(jù)文件可以采用本地文件，也可以使用網(wǎng)絡(luò)或分布式文件系統(tǒng)，或其他數(shù)據(jù)源。
要解決中間表問題，需要報表工具強化自身的計算能力才能實現(xiàn)！
參考資料：
【數(shù)據(jù)蔣堂】第 14 期：計算封閉性導(dǎo)致臃腫的數(shù)據(jù)庫
【數(shù)據(jù)蔣堂】第 15 期：開放的計算能力為數(shù)據(jù)庫瘦身
有效減少數(shù)據(jù)庫中間表的報表開發(fā)方法
為什么會有這么多中間表？

總結(jié)

以上是生活随笔為你收集整理的为什么多对多关系需要建立中间表_中间表是什么？和报表有什么关系？会带来怎样的问题？又如何解决？...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。