資料訪問層的優化思路

對於資料訪問層的優化，我簡單總結了一下，其實裡面有很多的點子現在想起來有一種靈光一現的感覺，但是真真切切的，裡面有不少是之前公司已經做到了的，所以一個做產品的公司真心很偉大，而能夠沉澱下來如此多的東西，那絕對是一筆非常寶貴的財富，對於公司，對於個人都是持久的財富。

簡單來說，如果處於初始階段，基本就是這樣的呼叫方式，資料訪問層是直連DB層面的，儘管從後期的演進來說，可能會有一層cache，但是這個暫且不在資料訪問層的優化範圍內來談。我們談偏左一些的設計和改進。

這樣的資料訪問層，短期內是不會有問題的，而隨著業務量增大，是肯定有問題的，問題實在太多我就講幾個重點的。

1. 可能因為系統的複雜程度，開發語言呢就有多重，不同的程式都需要訪問同一個DB,在上面運算元據，如此想來真是細思恐極，這裡面的資料隱患實在太多。

2. 不同的開發組都會有自己的資料處理流程和規範，所以大家都是各做各的，存在太多的冗餘，而且如果因為開發同學的SQL功底，確切的是說不夠細心認真，很可能會造成資料庫層面的各種潛在問題。

對此有一些改進方法，一種就是現成的，不同的業務模組和系統肯定對於不同的應用層面，那麼ERP的業務職能訪問ERP的表，這個也無可厚非了，至少的設計層面來看，這個要清晰些了。

而資料庫層面也必然是要做一些劃分，這個可以放在不同的資料庫使用者下，或者不同的業務表名。
總之就是要有針對性。

其實做到這裡，說實話，對問題沒有任何的改變，各個開發團隊還是自己的處理方式，如果需要新增資料表，那就初始化即可，自己提供SQL指令碼，DBA部署。看起來是這樣的，但是問題就是如此，裡面存在太多的不確定，我們完全沒法要求開發同學提供合適的約束名，索引名等，這些看起來似乎無關緊要的事情，其實深究起來還是蠻重要的。

怎麼改進呢，那就是下圖中的部分，我們在應用層面的物件和資料庫層面的表進行了對映，這個工具就是做這件事情的，而這個工具的本質工作是什麼呢，它會存放表的欄位資訊作為後設資料，對映到資料庫層面，就是SQL了。說簡單一些，這個工具就是eclipse的一個外掛，類似這樣的工具，無論是哪個開發團隊，都需要使用這個工具來進行應用和資料庫層面的資料表對映。

而SQL怎麼生成呢，通過這個圖形工具，因為得到了物件的配置後設資料，會基於這些資訊來生成標準的SQL語句。這樣就不用開發人員來牽扯更多初始化操作的部分了。

這樣做其實還是很給力的，而且在一定程度上能夠杜絕一大堆的潛在問題。

而接下來對於DBA來說就是一種夢魘了，那就是各個業務模組的變更多如牛毛。而且很多資料變更還存在一定的依賴性，或者說表在測試環境不需要初始化大量的分割槽，夠用即可，但是到了線上環境，就很有必要了，而且測試環境的結構應該儘量簡單，線上環境很可能是分散式的，資料庫使用者等配置就會格外複雜，對於這類的問題，很可能DBA就要從事更多的轉換，而且很可能是手工轉換工作。

對此一個很重要的改進就是使用PROFILE的改進，可以簡單理解為模板的概念。測試環境有一套測試環境的模板，線上環境有線上的模板，這樣一來初始化環境就會容易的多，而且不會那麼勞神費力。

而這兩個大問題解決之後能夠解決絕大多數資料訪問層的問題，那麼還有類問題，那就是對於應用層面物件的屬性變更，資料庫層面就會難做到聯動了。

我們可以用下面的圖來說明。

不同的應用模組有不同的資料庫訪問細則實現，我們就叫做DAO吧。如果對錶新增一個欄位或者修改物件屬性，這樣一來在資料庫訪問層沃恩就需要做更多額改進和對映，都說表裡的增刪改查其實就那麼回事，但是真攤到自己身上就是大事了，如果因為修改欄位資訊而需要動用修改核心的引用方式，就會給問題難上吉安娜。一格很單單的決定是，架構設計層面來完成這件事情，而難度最大的就是自動完成這些對映，而且DAO層面在這種情況下是不需要再次動用修改DAO層面的程式碼的，這個工作著實很難，而且很容易出現問題，但是確實做到了，而且用起來還真不錯。一個良好的架構設計就會在很大程度上簡化工作，使得開發同學不會糾結在更多的資料訪問層的細節，而更加業務情況，結合了具體的場景，那麼問題解決起來雖然是艱辛，但是回想起來還是希望能夠幫助到一些需要的朋友。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2128344/，如需轉載，請註明出處，否則將追究法律責任。