讓業(yè)務(wù)實現(xiàn)回歸數(shù)據(jù)庫

????? 讓時間回到2000年，當(dāng)年流行的MIS系統(tǒng)絕大多數(shù)均采用C/S架構(gòu)，也就是使用PowerBuilder/Delphi/VB等工具開發(fā)的胖客戶端通過OCI或其他接口直接連接Oracle或其他數(shù)據(jù)庫，業(yè)務(wù)邏輯在數(shù)據(jù)庫端實現(xiàn)，也就是通過PL/SQL、T-SQL語言等實現(xiàn)存儲過程、函數(shù)、觸發(fā)器等，由胖客戶端進行調(diào)用。C/S架構(gòu)，其中一個很大的問題是不利于擴展，由于Client直接連接數(shù)據(jù)庫，在業(yè)務(wù)繁忙的時候很容易把數(shù)據(jù)庫端的資源（連接數(shù)、服務(wù)器內(nèi)存等）耗盡，導(dǎo)致業(yè)務(wù)中斷甚至無法辦理。

?????? 為了解決這個問題，在C/S之間多加一層，同時把C端換成B端，也就是多加了一層中間層，同時把胖客戶端換成了瘦客戶端如瀏覽器等。數(shù)據(jù)庫連接由中間層進行管理，原來由存儲過程實現(xiàn)的業(yè)務(wù)邏輯改由中間層實現(xiàn)，這樣的做法讓不少的服務(wù)端語言（最著名的莫過于Java）得到了廣泛的推廣和應(yīng)用。B/S/S的架構(gòu)，讓數(shù)據(jù)庫的角色淪為了數(shù)據(jù)存儲器（Data Container）的角色，外加一些增刪改查的邏輯。隨著數(shù)據(jù)量的不斷增長，中間層與數(shù)據(jù)庫端的交互越來越頻繁，數(shù)據(jù)處理的低效與用戶希望快速高效的獲得結(jié)果的訴求之間矛盾顯得尤為突出。首先，數(shù)據(jù)從數(shù)據(jù)庫端傳送到中間層需要耗費時間；其次，使用中間層開發(fā)語言（大多數(shù)使用Java）處理大批量數(shù)據(jù)時，效率相對C/C++低效得多（尤其在系統(tǒng)資源利用上）；再次，處理完畢后如果還需要入庫，還需要一次網(wǎng)絡(luò)的傳輸。如何解決這個問題？讓業(yè)務(wù)實現(xiàn)回歸數(shù)據(jù)庫是行之有效的一種解決方法。

????? 讓業(yè)務(wù)實現(xiàn)回歸數(shù)據(jù)庫，并不是意味著業(yè)務(wù)應(yīng)用系統(tǒng)的開發(fā)要采用原有的C/S架構(gòu)，而是在三層結(jié)構(gòu)的基礎(chǔ)上，把部分業(yè)務(wù)邏輯的實現(xiàn)（尤其是需要頻繁數(shù)據(jù)交互和數(shù)據(jù)處理的地方）回到數(shù)據(jù)庫端實現(xiàn)，這時候可以使用C/C++這類高效的語言進行數(shù)據(jù)庫的擴展開發(fā)，在數(shù)據(jù)庫服務(wù)器端對大批量數(shù)據(jù)進行處理或分析，減少網(wǎng)絡(luò)的來回傳輸，提高系統(tǒng)的整體效率。

????? 數(shù)據(jù)庫的應(yīng)用系統(tǒng)業(yè)務(wù)邏輯如何高效實現(xiàn)？如果是Oracle/SQLServer的話，存儲過程不失為一個很好的選項，雖然這個選項讓人覺得很Low和倒行逆施、不合潮流，但卻是一個有效和高效的選項，特別是在以O(shè)racle為中心的應(yīng)用場景下。如果是PostgreSQL的話，除了存儲過程，還可以開發(fā)Extension，用C/C++、Python、Java甚至JS都可以，當(dāng)然，效率最高的莫過于C語言。

????? 與其在中間層上耗費大量的資源還不如在后臺數(shù)據(jù)庫上投入資源，形成數(shù)據(jù)庫集群，在分布式數(shù)據(jù)庫的應(yīng)用環(huán)境下，每個節(jié)點即時數(shù)據(jù)存儲節(jié)點也同樣是計算節(jié)點，簡單有效且高效。