引言
過去幾年中,我們將敏捷方法應用于數(shù)據(jù)庫設計,總結(jié)出一些技巧,使得當應用程序發(fā)展時,數(shù)據(jù)庫也能夠進化,這是敏捷方法的一個重要屬性。我們的方法是通過持續(xù)集成以及自動重構(gòu),通過數(shù)據(jù)庫管理人員(DBA)和應用開發(fā)人員的緊密合作來設計數(shù)據(jù)庫。這些技巧在應用開發(fā)的各個時期都有效。
1 敏捷方法學
近年來,出現(xiàn)了一種新的軟件開發(fā)方法學——敏捷方法學。這給數(shù)據(jù)庫設計提出了一些新的、巨大的需求。這些需求的一個中心就是進化設計。在一個敏捷項目中,需要假定我們并不能事先確定系統(tǒng)的需求,因此在項目的初期有一個詳細設計階段的想法是不現(xiàn)實的。系統(tǒng)的設計必須隨著軟件的變化而進化。敏捷方法,尤其是極限編程(XP),通過一些實踐使這種進化設計成為可能。在數(shù)據(jù)庫設計采用敏捷方法,反復迭代。
許多人會懷疑敏捷方法能否用于有大型數(shù)據(jù)庫組件的系統(tǒng),但我們的確使用了許多敏捷和XP技巧,用于解決基于大型數(shù)據(jù)庫的項目中的進化與迭代問題。
3 實踐
我們有關于數(shù)據(jù)庫進化設計的方法依賴于一些重要的實踐。
3.1 數(shù)據(jù)庫管理人員與開發(fā)人員緊密合作
敏捷方法的一個重要原則就是擁有不同技能和背景的人能夠緊密合作。正式的會議和文檔不能達到充分交流的效果,因此他們需要一直一起工作、親密合作。所有的項目組成員都需要緊密合作:系統(tǒng)分析人員、項目經(jīng)理、行業(yè)專家、開發(fā)人員以及數(shù)據(jù)庫管理人員(DBA)。
開發(fā)人員的每項工作可能都需要DBA的幫助,開發(fā)人員和DBA需要考慮是否需要對數(shù)據(jù)庫計劃做很大的改變。開發(fā)人員向DBA咨詢?nèi)绾螒獙ψ兓洪_發(fā)人員知道需要什么新的功能,而DBA對應用中的數(shù)據(jù)有全局的觀念。
為了達到親密合作的效果,DBA必須使自己易于接近。DBA需要留出幾分鐘的時間,讓開發(fā)人員來提問。必須確保DBA和開發(fā)人員坐在一起,這樣他們就很容易溝通。同時必須確保應用設計會議是公開的,這樣DBA可以隨時加入進來。在很多情況下我們發(fā)現(xiàn)人們在DBA和應用開發(fā)人員之間建立屏障,這些屏障必須去除,這樣進化數(shù)據(jù)庫設計才有可能。
3.2 每個項目組成員都有自己的數(shù)據(jù)庫實例
進化設計認為人們通過嘗試來進行學習,在編程期間開發(fā)人員在如何實施某個特征,應用某個首選的方案之前做一些試驗,數(shù)據(jù)庫設計也是如此。因此,每個開發(fā)人員都有自己用來試驗的實例,而不必影響其它人,這一點很重要,這樣每個人都可以根據(jù)自己的需要進行試驗。
許多DBA專家認為多個數(shù)據(jù)庫是一種麻煩,不易于實際應用,但我們發(fā)現(xiàn)操作一百個左右的數(shù)據(jù)庫是很容易的。當然其中很重要的是擁有便利的工具,使你像操作文件一樣操作數(shù)據(jù)庫。
3.3 開發(fā)人員數(shù)據(jù)庫經(jīng)常集成到共享主數(shù)據(jù)庫
盡管開發(fā)人員可以在他們自己的空間頻繁試驗,但是將不同的工作定期匯合也是很重要的。應用開發(fā)需要一個共享主數(shù)據(jù)庫,所有的工作都匯集于此。當開發(fā)人員開始工作時他們從主數(shù)據(jù)庫獲取拷貝到自己的工作空間,進行操作和修改,然后將變化反饋進入主數(shù)據(jù)庫。我們的規(guī)定是每個開發(fā)人員要每天提交匯合一次。
假設開發(fā)人員上午10點開始一項開發(fā)任務,這項任務的一部分是改變數(shù)據(jù)庫計劃。如果這種改變很簡單,如增加一個字段,他就可以自己決定。通過數(shù)據(jù)字典的幫助,開發(fā)人員還必須確保他想增加的字段數(shù)據(jù)庫中沒有,但是如果他與DBA討論這種可能的變化,那么工作就要簡單的多。
當他準備開始時,先從主數(shù)據(jù)庫中獲取一份拷貝,這樣就可以自由地改變數(shù)據(jù)庫計劃和代碼。因為他使用的是自己的數(shù)據(jù)庫實例,所以不會影響別人。在某個時候,如下午3點,他很清楚需要什么樣的數(shù)據(jù)庫變化,甚至此時他還沒有完全做完他的編碼工作。這時他找到DBA,告訴他想要的變化,這時DBA可以提出開發(fā)人員沒有考慮到的問題。當然大多數(shù)時候都很好,DBA同意這種變化(通過一個或多個數(shù)據(jù)庫重構(gòu))。DBA使變化馬上發(fā)生(除非他們是破壞性的變化),這樣開發(fā)人員可以繼續(xù)他的工作,在任何時候提交代碼,因為DBA已經(jīng)將這些變化發(fā)送給主數(shù)據(jù)庫。
可以將這個原則看作類似于持續(xù)集成,持續(xù)集成常用于源碼管理。實際上這就是將數(shù)據(jù)庫看作是另一種源代碼,因為配置管理系統(tǒng)象控制源代碼一樣控制主數(shù)據(jù)庫。只要我們構(gòu)建成功,數(shù)據(jù)庫和源代碼一起被送入配置管理系統(tǒng),這樣我們就有兩者完整和同步的版本歷史。
對于源代碼來說,集成中的問題被源代碼控制系統(tǒng)處理。對于數(shù)據(jù)庫來說,要做的工作稍微多一些,所有數(shù)據(jù)庫的變化都需要妥善處理,如自動化數(shù)據(jù)庫重構(gòu)。此外DBA需要審視任何數(shù)據(jù)庫變化,保證其符合整個數(shù)據(jù)庫的計劃。為了使這項工作做的比較平穩(wěn),在集成的過程中不應該出現(xiàn)大的變化——因此需要DBA與開發(fā)人員緊密合作。
我們強調(diào)經(jīng)常性的小集成,因為它比非經(jīng)常性的大集成容易得多。集成的復雜度會隨著集成的規(guī)模呈幾何級度增加,因此做許多小的變化在實踐中更易于實現(xiàn),當然這看上去與直覺相抵觸。
3.4 數(shù)據(jù)庫包含計劃和測試數(shù)據(jù)
當提到數(shù)據(jù)庫的時候,我們并不僅僅指數(shù)據(jù)庫計劃,而且還包括相當規(guī)模的數(shù)據(jù)。這些數(shù)據(jù)包括應用所需的標準數(shù)據(jù),如全國所有的省份名,以及一些樣本客戶的樣本數(shù)據(jù)。
數(shù)據(jù)的作用:
(1) 易于測試
使用大量的自動化測試可以幫助穩(wěn)定應用的發(fā)展,這樣的測試在敏捷方法里是常用的方法。為了使這些測試有效進行,很理智的方法是在一個有樣本測試數(shù)據(jù)的基礎上工作,這樣所有的測試可以在程序正式進行之前完成。
(2) 測試數(shù)據(jù)庫的遷移
除了測試代碼之外,樣本測試數(shù)據(jù)允許我們測試數(shù)據(jù)庫的遷移,當改變了數(shù)據(jù)庫的計劃后,我們還必須保證所有的計劃變更也能夠處理樣本數(shù)據(jù)。
在大多數(shù)項目中這些樣本數(shù)據(jù)是虛構(gòu)的,然而在某些項目中人們使用實際數(shù)據(jù)作為例子,在這些情況下,數(shù)據(jù)從先前由自動化數(shù)據(jù)遷移代碼的系統(tǒng)中提取出來。很明顯不能馬上遷移所有的數(shù)據(jù),因為在早期迭代中數(shù)據(jù)庫只有小部分建立起來。但是我們希望當應用和數(shù)據(jù)庫發(fā)展時,改變遷移代碼。這樣不僅能夠盡早解決遷移問題,也使行業(yè)專家易于處理這個正在開發(fā)的系統(tǒng)。因為有他們熟悉的數(shù)據(jù),所以他們會指出可能給數(shù)據(jù)庫和應用設計帶來問題的地方,因此我們建議在項目的早期迭代中引入實際數(shù)據(jù)。
北京 | 天津 | 上海 | 江蘇 | 山東 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
廣東 | 河北 | 湖南 | 廣西 | 河南 |
海南 | 湖北 | 四川 | 重慶 | 云南 |
貴州 | 西藏 | 新疆 | 陜西 | 山西 |
寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
黑龍江 | 內(nèi)蒙古 |