Question

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

你会推荐什么技术？

Answer 1

对于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

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

Answer 2

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

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

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

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

我们还有一个“发布”主数据库，我们应用更新，我们使用恢复的备份进行新安装（节省了运行脚本的时间，这显然随着时间的推移而增加）。我们更新为＆amp;什么时候，因为很明显，如果它有点陈旧，可以应用后来的补丁脚本。

我们的发布数据库还包含已清理的启动数据（在新安装上线之前被删除，或者有时被采用和修改 - 所以这不包含在任何更新脚本中）

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

Answer 3

我正在考虑的是向数据库添加一个SchemaVersion表，该表保存每个存在的版本的记录。 SchemaVersion表的最后一个版本是数据库的当前级别。

我将创建（SQL）脚本，执行1.0的初始设置，然后从1.0升级到1.1,1.1到1.2等。

即使是全新安装，例如1.2将运行所有这些脚本。这似乎有点慢，但只在一个（几乎）空的数据库上完成一次。

这样做的一大优点是全新安装将具有与升级安装相同的数据库架构。

正如我所说：我正在考虑这个问题。我明天可能会开始实施这个。如果您有兴趣，我可以分享我的经验。我将为一个c＃应用程序实现这个，该应用程序使用SQL Server和MySQL作为DBMS的LINQ到实体。

我有兴趣听到别人的建议和想法，如果有人能指出我的开源.Net库或实现类似这样的东西，那就太好了。

编辑：在对不同question here on SO的回答中，我找到了对Migrator.Net的引用。我今天开始使用它，看起来它正是我正在寻找的。

Answer 4

IMO最简单的方法是处理来自例如1.0到1.5作为一系列更新从1.0到1.1,1.1到1.2，依此类推。对于每个版本更改，请保留转换脚本/代码段。

然后，在数据库中保留一个带有版本字段的表，并将应用程序编译为所需的版本。在启动时，如果版本字段与编译版本不匹配，请逐个运行所有必需的转换脚本。

理想情况下，转换脚本应该在提交事务之前启动事务并将新版本作为最后一个语句写入数据库。

Answer 5

我在写作的.net应用程序中遇到了同样的问题。

最后，我编写了自己的升级框架来完成这项工作（不适合你，因为它是用C＃编写的）。您可能希望查看link text以获得一些想法。