我正在使用一个使用本地sqlite数据库的AIR应用程序,并且想知道当我分发新版本的应用程序时,如何管理数据库模式更新.还要考虑更新,跳过一些版本.例如.而不是从1.0到1.1,从1.0到1.5.
你会推荐什么技术？
解决方法
我们将每个DDL更改脚本写入数据库,当我们进行“发布”时,我们将它们连接成一个“升级”脚本,以及自“自上次以来”更改的任何存储过程
我们有一个表存储应用的最新补丁的版本号 – 所以升级工具可以应用任何更新的补丁.
每个存储过程都在一个单独的文件中.每个都以一个“插入”语句开始,记录表存储了SProc的名称,版本和“now”. (实际上,执行一个SProc来存储这个,而不是一个原始的insert语句).
有时在部署期间,我们手动更改SPRO,或推出几率和从DEV结束,并比较客户端的TEST和PRODUCTION数据库上的日志,使我们能够检查所有内容都是相同的版本.
我们还有一个“发布”主数据库,我们应用更新,并且我们使用恢复的备份进行新安装(节省了运行脚本的时间,这显然随着时间的推移而增加).我们更新为&何时,因为显然如果它有点过时,可以应用后来的补丁脚本.
我们的发布数据库还包含消毒的启动器数据(在新的安装生效之前被删除或有时采用和修改),因此这不包括在任何更新脚本中)
sql Server有一个工具栏按钮来编写更改 – 因此您可以使用GUI工具进行所有更改,而不是保存它们生成脚本. (实际上,有一个复选框总是生成一个脚本,所以如果你忘了,只是按SAVE它仍然给你使用的事后的脚本,可以保存为补丁文件)
