一种可能的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

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

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

其实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文件本身就是纯文本文件，可以在任何时候看，没有任何缺点。而数据库方式必须连接数据库，查询等等。

可以是可以！有没有想过版本回退的问题，如果分支较多的，当中间某个版本出现问题。所涉及的修正版本会很麻烦？

“其实sql的脚本数量不会很大，可以采用两种方式：全量/增量”
其实不然，有些项目甚至直接用SQL写业务逻辑，程序即数据。这时候感觉升级非常痛苦。

可以考虑用Liquibase，
http://www.liquibase.org/

感觉这个方式不错，可行。

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

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

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

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

google试试：dbdeploy