我有一个C#应用程序,它可以与Oracle数据库一起使用,并且已经发布.现在是时候发布新版本了.C#对象模型已经过修改,并对表结构产生了影响.
如果我发布新版本,我需要处理现有数据.只是删除表并重新创建这些表不会让任何客户满意.
为了解决这个问题,我收集了SQL脚本,它将先前发布的数据库结构改为新的数据库结构.在此过程中,数据也会迁移.SQL脚本被提交到C#源代码等存储库.在CruiseControl.NET的帮助下,定期测试数据库的修补程序.针对修补的数据库运行NUnit测试,以发现数据库表和C#对象模型之间的不匹配.
整个过程确实有效,但我觉得这可以做得更好.我认为数据库迁移非常关键.运送的应用程序无法使用错误修补的数据库,没有任何价值.丢失数据是不可接受的.这些恐怖场景可能会让我觉得根本不要改变数据库.因此,对我使用的工具和实践充满信心对我来说非常重要.
上周我偶然发现了LiquiBase,我问自己 - 现在在SO:
哪些工具或实践有助于以较低的风险和更大的信心进行数据库迁移?那里有好书或网络资源吗?
我对C#和Oracle的特定解决方案特别感兴趣,它可能适合我上面概述的开发过程.
数据库升级脚本必须是开发过程的一部分.以下是跟踪数据库架构升级的一种方法:
在数据库中创建包含一个版本号记录的VERSION表
每次更改应用程序的数据库模式时,您应该:
创建用于创建,更改或删除数据库对象的SQL脚本
创建用于管理必须使用新数据模式完成的数据更改的SQL脚本(例如,在新字段中插入默认值,在新表中插入默认记录,创建用于拆分或合并表的脚本,...)
增量数据库版本号
对于每个更改,我通常会创建一个名为DbVerXXXX.SQL的脚本,其中包含所有必要的升级(XXXX是版本号).此外,我会以小步骤进行更改 - 仅为您在应用程序中执行的下一次更改更改数据库架构.不要创建需要数周或数月才能升级应用程序的数据库升级.
创建将用户数据库升级到新版本的脚本:
脚本应检查当前版本的数据库,然后执行将模式转换为所需级别的数据库升级脚本
更改VERSION表中的版本号
此过程使您能够:
将所有数据库架构更改置于源代码管理下,以便您拥有完整的更改历史记录
在将测试数据库发送给客户之前,请尝试在测试数据库上测试它们
自信地自动升级用户数据库