现今开发的软件当中，多数系统的数据都是基于数据库存储的，但是由于软件变化的复杂性，相对于维护代码，数据库架构的版本并不是那么好维护。
这里本人针对实际情况，理想化出一种可以清晰理解的数据库架构脚本的版本控制机制。
请先看目录树：
1Example.DataSchema
2├─V1.0
3│ ├─Common
4│ │ 001.Create.Table.Product.sql
5│ │ 002.Create.Table.User.sql
6│ │ 003.Create.Table.Feedback.sql
7│ │ 004.Create.Table.Role.sql
8│ │ 005.Create.Function.FN_GetlProductCode.sql
9│ │ 006.Create.Function.USP_CleanFeedback.sql
10│ │
11│ ├─Enterprise
12│ │ 001.Create.Table.Highland.sql
13│ │
14│ └─Professional
15│ 001.Create.Table.Lowend.sql
16│
17├─V1.1
18│ ├─Common
19│ │ 001.Alter.Table.User.sql
20│ │ 002.Alter.Function.FN_GetlProductCode.sql
21│ │ 003.Drop.Function.USP_CleanFeedback.sql
22│ │
23│ ├─Enterprise
24│ │ 001.Alter.Table.Highland.sql
25│ │
26│ └─Professional
27│ 001.Alter.Table.Lowend.sql
28│
29└─V2.0
30 ├─Common
31 │ 001.Alter.Table.Product.sql
32 │ 002.Alter.Table.User.sql
33 │ 003.Create.Function.USP_CheckProduct.sql
34 │
35 ├─Enterprise
36 │ 001.Create.Table.Overland.sql
37 │
38 └─Professional
39 001.Alter.Table.Lowland.sql
40 002.Create.Table.Notebook.sql相信上面的目录结构还算明了，我们可以根据软件的版本追溯数据库，而不是通过版本控制工具来追溯原始数据库，而数字序号的前缀，更指明了脚本执行顺序，再也不用因为在建立数据库时受到依赖/外键关系的原因而运行脚本失败了。整个层次非常清晰，头脑通透的 Coder 相信可以一看便明了。
版本目录下有三个文件夹：Common, Professional, Enterprise，分别代表一个产品的三个定制化版本，因为软件中可能有这样的需求，软件基本结构不变，但是使用提供者模式提供了多个定制化版本，每个提供者的数据库结构基本相同，但是又有极少的差异。通过上面的这种管理机制，可以避免在源代码控制系统中开分支来维护，从某种程度上来说，提高了一定的可维护性。
这种管理机制类似于 ROR，不过 ROR 更 OO 一些，还能够隔离特定数据；通过这种机制，我们可以结合 RikMigrations 或 Migrator.NET 进行自动化的数据库升级(需要编码)。