现今开发的软件当中,多数系统的数据都是基于数据库存储的,但是由于软件变化的复杂性,相对于维护代码,数据库架构的版本并不是那么好维护。
这里本人针对实际情况,理想化出一种可以清晰理解的数据库架构脚本的版本控制机制。
请先看目录树:
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 进行自动化的数据库升级(需要编码)。