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

如果大家做过升级包，也许会有同感，即升级中最复杂的，就是数据库脚本的升级。

因为.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

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

这个方式我想过去觉得是可行的，大家有没有别的意见？

评论

1 楼 diyunpeng 2012-11-03  

我之前管理就是这样管理，在数据库里面存放一个版本记录表，然后在安装总入口处执行，查看需要安装那些升级包，注意的就是要按照时间排序，譬如12.11.11代表2012年11月11日做的升级包，这是我的思路，总体运行还可以，这样弄之后，即使是分布式多点部署了，也没问题，安装脚本会自动执行对应的升级包。