RikMigrations 或 Migrator.NET 进行自动化的数据库升级
2014-01-01 23:12
162 查看
一种版本化的数据库脚本管理机制
现今开发的软件当中,多数系统的数据都是基于数据库存储的,但是由于软件变化的复杂性,相对于维护代码,数据库架构的版本并不是那么好维护。
这里本人针对实际情况,理想化出一种可以清晰理解的数据库架构脚本的版本控制机制。
请先看目录树:
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 进行自动化的数据库升级(需要编码)。
现今开发的软件当中,多数系统的数据都是基于数据库存储的,但是由于软件变化的复杂性,相对于维护代码,数据库架构的版本并不是那么好维护。
这里本人针对实际情况,理想化出一种可以清晰理解的数据库架构脚本的版本控制机制。
请先看目录树:
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 进行自动化的数据库升级(需要编码)。
相关文章推荐
- ASP.NET中使用代码来进行备份和还原数据库
- Scott Mitchell 的ASP.NET 2.0数据教程之63:在事务里对数据库修改进行封装
- 使用postgreSQL DataSync 进行pg数据库升级 数据同步 升级脚本生成, postgreSQL DataSync简单教程
- 如何通过AgileEAS.NET快速搭建属于你的企业应用(二)——智能版本升级和多数据库访问的分布式部署
- 【方正中间件】用平台如何进行连远程服务器开发(.net版本/数据库SQLServer)
- 使用postgreSQL DataSync 进行pg数据库升级 数据同步 升级脚本生成, postgreSQL DataSync简单教程
- 使用升级脚本进行数据库版本管理及发布
- ASP.NET网站权限设计实现(一)——使用PowerDesigner进行数据库设计
- ASP.NET网站权限设计实现(一)——使用PowerDesigner进行数据库设计
- c#利用ado.net进行数据库开发的基本步骤
- [VB.NET]怎样对数据库中的所有记录进行搜索?
- ASP.NET数据导入至页面列表进行查看并最终保存到数据库
- (转)c#利用ado.net进行数据库开发的基本步骤
- 数据库迁移利器:Migrator.Net
- 使用postgreSQL DataSync 进行pg数据库升级 数据同步 升级脚本生成, postgreSQL DataSync简单教程
- 数据库迁移 Migrator.Net
- [辅助工具] 一个方便将ASP代码升级到ASP.NET的小工具 -- ASP Code Migrator!
- ASP.NET中使用代码来进行备份和还原数据库
- ASP.NET 使用类对数据库进行增删改查操作
- Goldengate辅助数据库进行升级