我正在使用本地SQLite数据库的AIR应用程序上工作，想知道在分发新版本的应用程序时如何管理数据库架构更新。还考虑跳过某些版本的更新。例如。而不是从1.0到1.1，而是从1.0到1.5。
您会推荐哪种技术？
最佳答案
我们将每个DDL更改写入数据库的脚本中，当我们进行“发行”时，我们将它们与单个“升级”脚本以及所有自“上次”以来已更改的存储过程连接在一起。
我们有一个表，其中存储了所应用的最新补丁程序的版本号-升级工具可以应用任何更新的补丁程序。
每个存储过程都在单独的文件中。每个命令都以“插入”语句开始到存储SProc的名称，版本和“现在”的日志表中。 (实际上是执行SProc来存储它，而不是原始的插入语句)。
有时在部署过程中，我们手动更改SProc或从DEV推出零零碎碎的费用，并比较客户端TEST和PRODUCTION数据库上的日志，使我们能够检查所有版本是否相同。
我们还有一个“发行版”主数据库，我们将在该数据库上应用更新，并对新安装使用该数据库的还原备份(节省了运行脚本的时间，随着时间的推移显然会增加)。我们将其更新为＆when，因为显然如果它有点陈旧，可以应用更高版本的补丁脚本。
我们的Release数据库还包含经过清理的入门数据(在新安装上线之前已删除或有时采用并修改了该数据-因此任何更新脚本中均未包含)
SQL Server有一个工具栏按钮来为更改编写脚本-因此，您可以使用GUI工具进行所有更改，而不必保存它们，而是生成脚本。 (实际上，有一个复选框可以让总是生成脚本，因此，如果您忘记了，只需按SAVE，它仍会为您提供事后使用的脚本，可以将其保存为补丁文件)
关于database - 数据库架构更新，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/550662/