数据库架构更新

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”语句开始，指向一个存储 SPproc 名称、版本和“now”的日志表。 （实际上执行一个 SProc 来存储它，它不是原始插入语句）。

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

我们还有一个“发布”主数据库，我们将更新应用到该数据库，并且我们使用该数据库的恢复备份来进行新安装（节省了运行脚本的时间，随着时间的推移，脚本的时间显然会增加）。 我们将其更新为 & 何时，因为显然如果它有点陈旧，可以应用以后的补丁脚本。

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

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

Answer 3

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

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

即使是全新安装到例如 1.2，也会运行所有这些脚本。 这可能看起来有点慢，但只在（几乎）空的数据库上完成一次。

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

正如我所说：我正在考虑这一点。 我可能明天就会开始实施这个。 如果你有兴趣我可以分享我的经验。 我将为使用 LINQ-to-entities 以及 SQL Server 和 MySQL 作为 DBMS 的 ac# 应用程序实现此功能。

我很想听听其他人的建议和想法，如果有人能给我指出一个实现类似功能的开源 .Net 库或类，那就太好了。

编辑：
在回答另一个问题时，我找到了对 Migrator.Net 的引用。 我今天开始使用它，看起来它正是我一直在寻找的东西。

Answer 4

IMO 最简单的做法是将例如从 1.0 到 1.5 的更新视为从 1.0 到 1.1、1.1 到 1.2 等的一系列更新。 对于每个版本更改，请保留一个转换脚本/一段代码。

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

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