浏览 3968 次
锁定老帖子 主题:一种可能的SQL脚本管理方式
精华帖 (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 如果不是要全量安装,而是要升级的话,就在升级脚本中提供入口,执行相应的脚本就可以了 这个方式我想过去觉得是可行的,大家有没有别的意见? 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间: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文件本身就是纯文本文件,可以在任何时候看,没有任何缺点。而数据库方式必须连接数据库,查询等等。 |
|
返回顶楼 | |
发表时间:2012-08-03
可以是可以!有没有想过版本回退的问题,如果分支较多的,当中间某个版本出现问题。所涉及的修正版本会很麻烦?
|
|
返回顶楼 | |
发表时间:2012-08-03
“其实sql的脚本数量不会很大,可以采用两种方式:全量/增量”
其实不然,有些项目甚至直接用SQL写业务逻辑,程序即数据。这时候感觉升级非常痛苦。 |
|
返回顶楼 | |
发表时间:2012-08-03
可以考虑用Liquibase,
http://www.liquibase.org/ |
|
返回顶楼 | |
发表时间:2012-08-03
感觉这个方式不错,可行。
|
|
返回顶楼 | |
发表时间: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 |
|
返回顶楼 | |
发表时间:2013-03-27
google试试:dbdeploy
|
|
返回顶楼 | |