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

上一篇:thinkphp5.0 空模块、空控制器、空方法


下一篇:用正则表达式抓取网页中的ul 和 li标签中最终的值!