论坛首页 Java企业应用论坛

一种可能的SQL脚本管理方式

浏览 3968 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2012-07-31  
如果大家做过升级包,也许会有同感,即升级中最复杂的,就是数据库脚本的升级。

因为.class,.jsp等文件,即使2个版本天差地别,大不了全量替换就可以了。但是对于sql脚本,就没有这么简单了。哪怕不考虑业务数据备份的问题,光是表结构和初始化数据的变更,就已经很麻烦了

对于集中部署的应用,这种情况还好一些,如果应用是在各个局点有不同的版本,那就需要制作不同的升级包,这个麻烦就被更加放大了

以前想到了一些管理手段来缓解这个问题,比如将sql脚本集中存放,比如对于sql的变动加以详细记录等

今天是要总结一个新的方法,听同事说起的,我觉得可能是可行的,在此记录一下。下个版本实践试试看

举例来说,应用第1个版本,安装包里有一系列sql脚本,比如说叫做init.sql,里面有一句sql是
insert into USER values ("1","kitty","female");

第2个版本,需要对这条初始化数据进行修改,有一种办法是,修改init.sql为
insert into USER values ("1","superman","male");

这样的话,如果一个局点,已经跑着第1个版本,现在要升级到第2个版本,那就需要写一个新的升级脚本update.sql
update USER set NAME = 'superman', Sex = 'male' WHERE ID = '1';

我的同事就提出一个方案,即在版本发布以后,就不对原有的sql脚本进行修改,而是根据版本提供升级脚本,放在相应的目录里。

比如说

/version1.0/init.sql
/version1.1/update_1.1.sql
/version1.2/update_1.2.sql

然后在安装脚本里提供入口,如果是1.0版本的安装包,就仅仅执行init.sql;如果是1.1版本的安装包,就执行init.sql和update_1.1.sql

如果不是要全量安装,而是要升级的话,就在升级脚本中提供入口,执行相应的脚本就可以了

这个方式我想过去觉得是可行的,大家有没有别的意见?
   发表时间:2012-08-01   最后修改:2012-08-01
其实sql的脚本数量不会很大,可以采用两种方式:全量/增量

全量:
init.1.sql
init.2.sql
init.2.1.sql
或者时间戳
init-2012-11-11.sql
init-2012-11-12.sql

增量
init.sql
update.1.sql

写个自动化脚本,自动执行相应的sql即可。

.sql文件本身就是纯文本文件,可以在任何时候看,没有任何缺点。而数据库方式必须连接数据库,查询等等。
0 请登录后投票
   发表时间:2012-08-03  
可以是可以!有没有想过版本回退的问题,如果分支较多的,当中间某个版本出现问题。所涉及的修正版本会很麻烦?
0 请登录后投票
   发表时间:2012-08-03  
“其实sql的脚本数量不会很大,可以采用两种方式:全量/增量”
其实不然,有些项目甚至直接用SQL写业务逻辑,程序即数据。这时候感觉升级非常痛苦。
0 请登录后投票
   发表时间:2012-08-03  
可以考虑用Liquibase,
http://www.liquibase.org/
0 请登录后投票
   发表时间:2012-08-03  
感觉这个方式不错,可行。
0 请登录后投票
   发表时间:2013-02-26  
jinnianshilongnian 写道

其实sql的脚本数量不会很大,可以采用两种方式:全量/增量

写个自动化脚本,自动执行相应的sql即可。



从lz描述的情况来看,可以采用增量的方式。

其实,实际项目维护中也是采用增量方式来维护sql脚本。lz列出来的方式是非常可行的。

一点改进意见就是可以吸收rails的经验,加上时间戳,最好也加上修改原因

/v1.0/init.sql
/v1.1/bug_fixed_HHHHmmss.sql
/v1.2/add_column_xx_HHHHmmss.sql


0 请登录后投票
   发表时间:2013-03-27  
google试试:dbdeploy
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics