現今開發的軟體當中，多數系統的資料都是基於資料庫儲存的，但是由於軟體變化的複雜性，相對於維護**，資料庫架構的版本並不是那麼好維護。
這裡本人針對實際情況，理想化出一種可以清晰理解的資料庫架構指令碼的版本控制機制。
請先看目錄樹：
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
資料庫中的一種條件查詢 case when
在最近的一場筆試中，遇到這樣一道sql的題目。有一張表如下 要通過查詢語句得到以下結果 知識點 case 搜尋函式 1 簡單的case函式 case clo name 列名 when value1 列值 then value1 value1 是我們賦予的值 when value2 列值 then v...
資料庫的另一種設計方法
最近參與了乙個專案的開發，在開發的過程中發現資料庫的設計有點意思，順便拿來給大家分享一下。對於乙個專案來說，資料庫無疑是很重要，如果資料庫設計不好，專案就很難開發的優秀，所以乙個資料庫的設計就顯得尤其重要。在我這個專案中，有乙個訂單表 orderform 乙個商品資訊表 googsinfo 乙個系統...
Redis 另一種資料庫
最近與同學聊天過程時，兩人聊到了redis，很詫異於該同學對redis方面知識的匱乏，便對redis做乙個簡略的總結 資料庫我們都知道，也都非常熟悉mysql資料庫的使用，於是會想當然的認為資料庫都是同源的，在這種想法下，會對redis不以為然，這樣，在工作時，將會對其手足無措，由於在工作中的需要，...