原文地址：http://blog.csdn.net/tywo45/article/details/2480078

1、概述

　　版本化資料庫的起點——建立一個數據庫Schema基線，這個基線是一些資料庫指令碼（包括create table，alter table，drop table，insert data，update data，delete data等）。這些指令碼可以位於同一.sql檔案中，也可根據其它規劃分別位於不同檔案中，例如將檢視指令碼，初始化資料指令碼，建表指令碼分別置於不同的檔案中。

2、版本化資料庫過程

　　資料庫版本化與程式碼版本化的區別在於資料庫中的生產資料是現場（即使用者）創造的，當我們的表結構發生改變時，不能直接用drop table然後再create table，因為這樣會導致生產資料丟失。而程式碼則完全由開發人員創造，可以用完全覆蓋的方式升級。由於這點不同，致使資料庫在版本化的過程中必然要採用與程式碼不同的方法。
　　軟體過程有一個過程方法叫迭代過程。對資料庫的版本化，我覺得也可以採用這種類似的方法------後一個版本的指令碼依賴於前一個版本的指令碼，即當你要把資料庫升級到第n個版本時，你必須先把資料庫升級到第(n-1)個版本，以此遞迴。方法很簡單，但實際的過程並不會太順利，設想以下一個場景來描述一些常見的困難和問題。
　　人力系統在V2.0.14版本時，有一張表叫demo_user，這張表有兩個欄位id和name，在我們進行V2.0.16版本的開發時，使用者提出了要有cn_name（中文名）資訊，並且這個資訊不允許為空，如果為空，則必須用“無中文名”顯示。這是個很簡單的需求，我們只需要在demo_user表中新增一個cn_name欄位即可------alter table demo_user add cn_name varchar2(64) not null;這個看似沒有錯誤的語句，實際上是行不通的-----因為現場的這張表是有資料的，我們執行這條語句時會報下圖所示的錯誤。
有經驗的程式設計師可能想到了解決方法------將本來一條可以搞定的SQL分成三條，分別為：

alter table demo_user add cn_name varchar2(64) null;
update demo_user set cn_name = '無中文名';
alter table demo_user modify cn_name varchar2(64) not null;

　　再設想，在V2.0.16版本時，日本有家公司要用我們公司的人力系統，我們的資料庫如何直接從無到V2.0.16版本？
　　很容易想到的一個方法是利用遞迴法，從第一個版本的指令碼開始跑，一直跑到V2.0.16。如果我們中間經歷了1000個版本，那就跑1000遍吧。實施的要哭了！面對重複性勞動時，人們都會抽象出一種比較好的方法來處理，就像設計模式中的狀態模式代替無窮的if else語句一樣，我們用各版本的全量指令碼來代替增量指令碼。這話不太好懂，以上面場景的demo_user表為例來說明一下吧。
以增量指令碼的形式，我們會有三條SQL：

alter table demo_user add cn_name varchar2(64) null;
update demo_user set cn_name = '無中文名';
alter table demo_user modify cn_name varchar2(64) not null;

但以全量指令碼的形式，我們只有一條SQL：

create table demo_user
(
ID VARCHAR2(18) not null,
NAME VARCHAR2(60) not null,
CN_NAME VARCHAR2(64) not null
);

　　看到上面的全量和增量，有何感想？是不是覺得全量指令碼只能用於新增局點，而已有局點，只能用增量指令碼？是的，全量指令碼就是給新增局點用的，但是目前，我覺得我們還不需要提供全量指令碼------原因是，維護全量指令碼給我們帶來的實惠要遠遠少於我們的付出。
　　再設想一個場景，日本局點不需要cn_name，他需要的是jp_name（日本名字）--------都說日本人bt，不過這個需求一點也不bt。如何做到呢？… …不累贅了，直接地說吧，此場景說明了，我們的指令碼需要做到差異化控制，所以差異化控制功能必須納入到控制範圍，至於如何做到差異化控制？接著看吧！
　　以上說得哆嗦了點，下面說說我們將資料庫版本化後，在VSS（或其它版本控制軟體工具）下的目錄結構吧！見下圖，相信圖來得夠直接了，俺就不哆嗦了：

　　　　　　　　　　　　　　　　圖2.1

3、問題列表

以專案的實際情況舉例，其實各種情況都可以泛化的 1，是否需要建一個oracle和sybase目錄，以區分對待主業和實業。 答：這是個偽問題。我們同一個版本只會發往主業或實業中的一個，所以不存在用oracle和sybase這樣的目錄來區分。如果實業的改動和主業的改動一樣，那麼就分別在主業版本和實業版本都加上相應的指令碼。 2，開發要做哪些事？QA要做哪些事？實施要做哪些事？ 答： 開發要做的： 　　1、提供資料庫指令碼，包括共用指令碼和差異化指令碼 　　2、寫好rs_build.sql QA要做的：        1、釋出新版本時，需要將上一版本的指令碼複製到新版本的歷史指令碼中一併釋出（參見圖2.1）。 實施要做的： 　　1、修改rs_execute_sql.bat指令碼（就是將使用者名稱、密碼和資料庫名修改成相應的就可以了） 　　2、雙擊execute.bat以執行指令碼 　　3、從.log檔案中檢查是否有錯，如果發現錯誤，及時和開發人員溝通，然後由開發人員處理異常情況。

4、資料庫版本管理產品

• SQL Source Control
• DBV資料庫版本管理工具
• Flyway
• dbdeploy
• liquibase

5、後記

　　資料庫版本化看似是個可有可無的過程，但做好了，可以減少開發和實施的許多事情，我們的系統就是個活生生的例子。之前在newland公司的時候，開發部門也沒有資料庫指令碼控制，上個月聽說那個部門已經接近解散了。本文所闡述的方法是來自以前在ht時的經驗做法，但根據以前的一些問題作了些許改進。軟體公司的發展都會經歷從幼稚到成熟，借鑑其它公司的成功經驗，提前認識並解決問題可減少損失。