3.5 所有的變化應該數據庫重構

    重構技術就是應用所有可控技術來改變現有的代碼基礎，與此類似我們定義了數據庫重構也給數據庫的改變提供了類似的控制。

    數據庫重構的不同之處在于它必須將三種不同的變化同時完成：

(1) 改變數據庫計劃

(2) 進行數據遷移

(3) 改變數據庫存取代碼

    于是當描述數據庫重構時，我們必須描述變化的三個方面，并確保在應用另一個重構之前完成了這三種變化。

    我們必須文檔化不同的數據庫重構，因此我們還不能詳細描述他們。然而這里有幾點需要指出：像代碼重構一樣，數據庫重構非常微��；概念鏈一系列微小的變化，數據庫和代碼很相似；變化的三個屬性使保持小的變化更加重要。

    許多數據庫重構，如增加一個字段，可以不必更新所有存取系統的代碼來完成。但是如果在使用新計劃之前并不了解它，該字段將會無用，因為新計劃不知道其變化之處。許多變化，沒有考慮整個系統計劃，我們稱之為破壞性變化，如將一個已經存在的空值列設置為非空。破壞性變化需要多加留心，留心的程度依賴于包含破壞性的程度。一個小破壞性的例子是將一個已經存在的空值列設置為非空，在這種情況下你可以蒙著頭做。

    而重構將考慮數據庫中空值數據，開發人員將更新數據庫映射代碼，因此更新不會破壞其它人的代碼；如果偶然會破壞，開發人員將在建立和使用測試時發現問題。

    將一個經常使用的表分成兩個是一種更復雜的破壞。在這種情況中提前讓所有人知道變化到來很重要，這樣他們可以有所準備。此外應該在一個更安全的時刻來實施變化。這里面很重要的一點是選擇適用于你做出的變化的過程。

3.6 自動重構

    在代碼世界中許多語言能夠實現自動重構。在計劃變化和數據遷移過程中，這種自動化對于數據庫也非常重要。因此每個數據庫重構都可以通過編寫SQL DDL（對于計劃變化）和DML（對于數據遷移）來完成。這些變化不是通過手工實現，而是通過一些SQL語句來自動實現變化。

    一旦完成代碼，我們保存這些代碼文件來產生數據庫變化的完整的變化記錄，作為數據庫重構的結果。我們于是可以更新任何實例到最新的主數據庫，通過運行在我們拷貝主數據庫來產生更早的數據庫實例的變化記錄。

    自動化變化的序列化是對于持續集成和遷移產品數據庫的一個基本功能。

    為了最后產品數據庫我們并不在常規迭代周期中實施變化，我們在每一個發布之間建立完整的數據庫重構變化日志。毫無疑問，這是一個巨大的變化，我們必須離線實施該變化，在實際應用之前先測試遷移計劃絕對是明智之舉。迄今為止，這項技術相當管用，通過將大變化分解為小的簡單的變化，我們可以對產品數據進行大的變化，同時又不會給我們太多的麻煩。套用兵法中的一句話，就是“化整為零”。

    除了自動化向前的變化，我們也要考慮重構時向后的變化，如果能夠做到這樣就可以回到以前的數據庫狀態。在我們的項目中并沒有這樣做，因為沒有這個需求，但這同樣是很重要的基本原則。

3.7 自動地更新所有開發人員的數據庫

    人們變化和更新主數據庫，但是如何發現主數據庫已經發生變化？在傳統的持續集成有源代碼的環境中，開發人員在提交變化之前先更新主數據庫。這樣他們就可以在提交變化給共享主數據庫之前，解決他們自己的機器上的問題。

    每次主數據庫發生改變時，我們都要更新開發人員的數據庫。當主數據庫發生變化時，我們自動化更新所有項目成員的數據庫。相同的重構代碼更新主數據庫上的同時，自動更新成員數據庫。也許有人認為在開發人員不知情的情況下，更新開發人員數據庫會產生很多問題，但在實踐中我們沒發現什么問題。當然，這只在人們聯網時管用。所以當開發人員離線時，必須盡快與主數據庫重新保持同步。

3.8 清晰地分離所有的數據庫獲取代碼

    為了理解數據庫重構的結果，了解應用程序如何使用數據庫也非常重要。如果SQL語句分布在代碼基礎周圍，則很難這樣去做。因此一個清晰的數據庫獲取層很重要，它用來顯示數據庫如何被使用，在哪里被使用。

    清晰的數據庫層有很多好處。它減少了開發人員操縱數據庫時需要使用SQL知識的地方，這樣使對SQL語句不太熟悉的開發人員更易開發。對于DBA來說，給他提供了清晰的代碼，可以清楚地了解數據庫將如何使用。這也幫助準備索引、數據庫優化，優化SQL語句，使DBA更好地理解數據庫如何被使用。