`
blue2048
  • 浏览: 183777 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

数据库版本化-dbdeploy

阅读更多
Dbdeploy
需求——
数据库版本化与代码版本化的区别在于数据库中的生产数据是现场(即用户)创造的,当我们的表结构发生改变时,不能直接用drop table然后再create table,因为这样会导致生产数据丢失。而代码则完全由开发人员创造,可以用完全覆盖的方式升级。由于这点不同,致使数据库在版本化的过程中必然要采用与代码不同的方法。

功能——
完成数据库结构版本化,方便回滚,也可以完成数据库数据的回滚,但是一般不使用。在项目开发过程中,不断验证数据库脚本的正确性,在项目部署之初,可以方便的部署数据库。

原理——
在已存在一张user表,包含字段ID和NAME的情况下,需要添加新的ADDRESS字段,
全量脚本
create table user{
ID VARCHAR(18) not null,
NAME VARCHAR(60) not null,
ADDRESS VARCHAR(80) not null
};

增量脚本
alter table user add ADDRESS VARCHAR(80) null
update user set ADDRESS=’地址’
alter table user modify ADDRESS VARCHAR(80) not null

这是普通的增量脚本,dbdeploy的工作是使用增量脚本完成对数据库结构的变更,增量脚本格式
1 create users table.sql
数据库中有一张changLog表,记录版本号,从而使dbdeploy知道哪些增量脚本已经提交到数据库

在跟乔老板聊过后,发现dbdeploy的增量脚本中是需要写——有待验证
alter table user add ADDRESS VARCHAR(80) not null;
alter table user drop COLUMN ADDRESS //此句供dbdeploy回滚使用

并且表结构的变更,对表数据的影响有限,表中数据总量不会发生变化,字段可能发生变化。

每次对ddl的修改都使用增量脚本的方式,记录数据库结构的变化

优点——
1. 方便自动构建部署,满足了包括db在内的所有代码可以进行持续集成和顺利迁移
2. 在数据库版本的不断升级过程中,不断验证脚本的正确性
缺点——
1.      需要在数据中添加changelog表,不是完全的自动化
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics