RikMigrations 或 Migrator.NET 进行自动化的数据库升级

一种版本化的数据库脚本管理机制

  现今开发的软件当中，多数系统的数据都是基于数据库存储的，但是由于软件变化的复杂性，相对于维护代码，数据库架构的版本并不是那么好维护。

  这里本人针对实际情况，理想化出一种可以清晰理解的数据库架构脚本的版本控制机制。

  请先看目录树：

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 进行自动化的数据库升级(需要编码)。