? 現今開發的軟件當中，多數系統的數據都是基于數據庫存儲的，但是由于軟件變化的復雜性，相對于維護代碼，數據庫架構的版本并不是那么好維護。

? 這里本人針對實際情況，理想化出一種可以清晰理解的數據庫架構腳本的版本控制機制。

? 請先看目錄樹：

Example.DataSchema
├─V1.0
│? ├─Common
│? │????? 001.Create.Table.Product.sql
│? │????? 002.Create.Table.User.sql
│? │????? 003.Create.Table.Feedback.sql
│? │????? 004.Create.Table.Role.sql
│? │????? 005.Create.Function.FN_GetlProductCode.sql
│? │????? 006.Create.Function.USP_CleanFeedback.sql
│? │
│? ├─Enterprise
│? │????? 001.Create.Table.Highland.sql
│? │
│? └─Professional
│????????? 001.Create.Table.Lowend.sql
│
├─V1.1
│? ├─Common
│? │????? 001.Alter.Table.User.sql
│? │????? 002.Alter.Function.FN_GetlProductCode.sql
│? │????? 003.Drop.Function.USP_CleanFeedback.sql
│? │
│? ├─Enterprise
│? │????? 001.Alter.Table.Highland.sql
│? │
│? └─Professional
│????????? 001.Alter.Table.Lowend.sql
│
└─V2.0
??? ├─Common
??? │????? 001.Alter.Table.Product.sql
??? │????? 002.Alter.Table.User.sql
??? │????? 003.Create.Function.USP_CheckProduct.sql
??? │
??? ├─Enterprise
??? │????? 001.Create.Table.Overland.sql
??? │
??? └─Professional
??????????? 001.Alter.Table.Lowland.sql
??????????? 002.Create.Table.Notebook.sql

? 相信上面的目錄結構還算明了，我們可以根據軟件的版本追溯數據庫，而不是通過版本控制工具來追溯原始數據庫，而數字序號的前綴，更指明了腳本執行順序，再也不用因為在建立數據庫時受到依賴/外鍵關系的原因而運行腳本失敗了。整個層次非常清晰，頭腦通透的 Coder 相信可以一看便明了。

? 版本目錄下有三個文件夾：Common, Professional, Enterprise，分別代表一個產品的三個定制化版本，因為軟件中可能有這樣的需求，軟件基本結構不變，但是使用提供者模式提供了多個定制化版本，每個提供者的數據庫結構基本相同，但是又有極少的差異。通過上面的這種管理機制，可以避免在源代碼控制系統中開分支來維護，從某種程度上來說，提高了一定的可維護性。

? 這種管理機制類似于 ROR，不過 ROR 更 OO 一些，還能夠隔離特定數據；通過這種機制，我們可以結合 RikMigrations ?或 Migrator.NET ?進行自動化的數據庫升級(需要編碼)。

?

2009-07-29 Zealic

一種版本化的數據庫腳本管理機制