数据库架构更新

我正在使用一个使用本地SQLite数据库的AIR应用程序,并且想知道在分发应用程序的新版本时如何管理数据库架构更新.还考虑跳过某些版本的更新.例如,而不是从1.0到1.1,从1.0到1.5.

你会推荐什么技术？

对于SQLite,您可以使用user_version pragma来跟踪数据库的版本.要获得版本:

PRAGMA user_version

要设置版本:

PRAGMA user_version = 5

然后,我将每组更新保存在一个SQL文件(嵌入在应用程序中)中,并运行所需的更新以获得最新版本:

Select Case currentUserVersion
Case 1
  // Upgrade to version 2
Case 2
  // Upgrade to version 3
Case etc...
End Select

这允许应用程序将自身更新为最新版本,而不管当前版本的数据库.

我们将每个DDL更改编写到数据库中,当我们进行"发布"时,我们将它们连接到一个"升级"脚本,以及"自上次"以来已更改的任何存储过程

我们有一个表,用于存储应用的最新补丁的版本号 - 因此升级工具可以应用任何较新的补丁.

每个存储过程都在一个单独的文件中.每个都以"insert"语句开头,该语句存储到存储名称SProc,Version和"now"的日志表中.(实际上执行SProc来存储它,它不是原始插入语句).

有时在部署期间,我们手动更改SProc,或从DEV推出赔率和结束,并且比较客户端的TEST和PRODUCTION数据库上的日志使我们能够检查所有内容是否都在同一版本.

我们还有一个"发布"主数据库,我们应用更新,并为新安装使用恢复的备份(节省了运行脚本的时间,这显然会随着时间的推移而增加).我们会及时更新,因为很明显,如果它有点陈旧,可以应用后来的补丁脚本.

我们的发布数据库还包含已清理的启动数据(在新安装上线之前删除,或有时采用和修改),因此任何更新脚本都不包含此数据

SQL Server有一个工具栏按钮来编写更改脚本 - 因此您可以使用GUI工具进行所有更改,而不是保存它们而不是生成脚本.(实际上,有一个复选框可以始终生成一个脚本,因此如果您忘记并按下SAVE,它仍会为您提供事后使用的脚本,可以保存为补丁文件)