1、 易于測試
使用大量的自動化測試可以幫助穩定應用的發展。這樣的測試在敏捷方法里是常用的方法。為了使這些測試有效進行，很理智的方法是在一個有樣本測試數據的基礎上工作，這樣所有的測試可以在程序正式進行之前完成。
2、測試數據庫的遷移
除了測試代碼之外，樣本測試數據允許我們測試數據庫的遷移，當改變了數據庫的計劃后，我們還必須保證所有的計劃變更也能夠處理樣本數據。
在大多數項目中這些樣本數據是虛構的。然而在某些項目中人們使用實際數據作為例子。在這些情況下，數據從先前由自動化數據遷移代碼的系統中提取出來。很明顯不能馬上遷移所有的數據，因為在早期迭代中數據庫只有小部分建立起來。但是我們希望當應用和數據庫發展時，改變遷移代碼。這樣不僅能夠盡早解決遷移問題，也使行業專家易于處理這個正在開發的系統。因為有他們熟悉的數據，所以他們會指出可能給數據庫和應用設計帶來問題的地方。因此我們建議在項目的早期迭代中引入實際數據。
3.5所有的變化應該數據庫重構
重構技術就是應用所有可控技術來改變現有的代碼基礎。與此類似我們定義了數據庫重構也給數據庫的改變提供了類似的控制。
數據庫重構的不同之處在于它必須將三種不同的變化同時完成：
* 改變數據庫計劃
* 進行數據遷移
* 改變數據庫存取代碼
于是當描述數據庫重構時，我們必須描述變化的三個方面，并確保在應用另一個重構之前完成了這三種變化。
我們必須文檔化不同的數據庫重構，因此我們還不能詳細描述他們。然而這里有幾點需要指出：像代碼重構一樣，數據庫重構非常微小。概念鏈一系列微小的變化，數據庫和代碼很相似。變化的三個屬性使保持小的變化更加重要。
許多數據庫重構，如增加一個字段，可以不必更新所有存取系統的代碼來完成。但是如果在使用新計劃之前并不了解它，該字段將會無用，因為新計劃不知道其變化之處。許多變化，沒有考慮整個系統計劃，我們稱之為破壞性變化，如將一個已經存在的空值列設置為非空。破壞性變化需要多加留心，留心的程度依賴于包含破壞性的程度。一個小破壞性的例子是將一個已經存在的空值列設置為非空，在這種情況下你可以蒙著頭做。
而重構將考慮數據庫中空值數據。開發人員將更新數據庫映射代碼，因此更新不會破壞其它人的代碼；如果偶然會破壞，開發人員將在建立和使用測試時發現問題。
將一個經常使用的表分成兩個是一種更復雜的破壞。在這種情況中提前讓所有人知道變化到來很重要，這樣他們可以有所準備。此外應該在一個更安全的時刻來實施變化。
這里面很重要的一點是選擇適用于你做出的變化的過程。
3.6自動重構
在代碼世界中許多語言能夠實現自動重構。在計劃變化和數據遷移過程中，這種自動化對于數據庫也非常重要。因此每個數據庫重構都可以通過編寫SQL DDL（對于計劃變化）和DML（對于數據遷移）來完成。這些變化不是通過手工實現，而是通過一些SQL語句來自動實現變化。
一旦完成代碼，我們保存這些代碼文件來產生數據庫變化的完整的變化記錄，作為數據庫重構的結果。我們于是可以更新任何實例到最新的主數據庫，通過運行在我們拷貝主數據庫來產生更早的數據庫實例的變化記錄。
自動化變化的序列化是對于持續集成和遷移產品數據庫的一個基本功能。
為了最后產品數據庫我們并不在常規迭代周期中實施變化。我們在每一個發布之間建立完整的數據庫重構變化日志。毫無疑問，這是一個巨大的變化，我們必須離線實施該變化。在實際應用之前先測試遷移計劃絕對是明智之舉。迄今為止，這項技術相當管用。通過將大變化分解為小的簡單的變化，我們可以對產品數據進行大的變化，同時又不會給我們太多的麻煩。套用兵法中的一句話，就是“化整為零”。
除了自動化向前的變化，我們也要考慮重構時向后的變化。如果能夠做到這樣就可以回到以前的數據庫狀態。在我們的項目中并沒有這樣做，因為沒有這個需求，但這同樣是很重要的基本原則。
3.7自動地更新所有開發人員的數據庫
人們變化和更新主數據庫，但是如何發現主數據庫已經發生變化？在傳統的持續集成有源代碼的環境中，開發人員在提交變化之前先更新主數據庫。這樣他們就可以在提交變化給共享主數據庫之前，解決他們自己的機器上的問題。
每次主數據庫發生改變時，我們都要更新開發人員的數據庫。當主數據庫發生變化時，我們自動化更新所有項目成員的數據庫。相同的重構代碼更新主數據庫上的同時，自動更新成員數據庫。也許有人認為在開發人員不知情的情況下，更新開發人員數據庫會產生很多問題，但在實踐中我們沒發現什么問題。當然，這只在人們聯網時管用。所以當開發人員離線時，必須盡快與主數據庫重新保持同步。
3.8清晰地分離所有的數據庫獲取代碼
為了理解數據庫重構的結果，了解應用程序如何使用數據庫也非常重要。如果SQL語句分布在代碼基礎周圍，則很難這樣去做。因此一個清晰的數據庫獲取層很重要，它用來顯示數據庫如何被使用，在哪里被使用。
清晰的數據庫層有很多好處。它減少了開發人員操縱數據庫時需要使用SQL知識的地方，這樣使對SQL語句不太熟悉的開發人員更易開發。對于DBA來說，給他提供了清晰的代碼，可以清楚地了解數據庫將如何使用。這也幫助準備索引、數據庫優化，優化SQL語句，使DBA更好地理解數據庫如何被使用。
4 變化法則
如同任何實踐一樣，這些原則必須根據你特殊的環境變化。沒有一成不變的項目，我們必須要應對變化。
4.1保持多個數據庫在一個系統中
簡單項目也許只需要一個主數據庫。但是復雜項目需要有多個數據庫，即數據庫系。如果在投入生產之前數據庫必須分支，那么我們可以創建新的數據庫系。數據庫系類似于代碼的分支，需要不同測試數據集來進行測試。
當開發人員從主數據庫中獲取了一份拷貝，必須注冊他們在修改哪個數據庫系。當DBA更新主數據庫某個數據庫系時，同時更新了所有注冊這個數據庫系的開發人員的數據庫。
4.2不需要專職的DBA
所有這些聽上去好像需要大量的工作，但它并不需要大量的人力資源。在最大的項目中，我們有30個開發人員，項目組規模100人（包括質量評價、分析人員和管理人員），我們大概有100多個不同系列的產品分布在各工作站上。但所有這些工作只需要一個專職DBA，只有兩個編程人員業余幫忙。
在小項目中甚至不需要專職DBA。當我們將這些技巧用于更小的項目--12人左右的小項目時，發現該項目不需要一個專職的DBA。與此相反，我們依靠兩個對數據庫感興趣的開發人員業余處理DBA任務。
這是自動化的功勞。如果對每項任務進行自動化處理，就可以用更少的人來完成更多的工作。
5輔助工具
文章來源于領測軟件測試網 http://www.kjueaiud.com/
