我正在开发一个使用本地SQLite数据库的AIR应用程序，想知道如何在分发新版本的应用程序时管理数据库模式更新。同时考虑跳过某些版本进行更新。例如，从1.0直接升级到1.5，而不是从1.0升级到1.1。
您会推荐哪种技术？
4个回答
36
在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
这允许应用程序更新自己到最新版本，而不管当前DB的版本如何。
- Paul Lefebvre
1
7
我们对数据库中的每个DDL更改进行脚本编写，当我们进行“发布”操作时，我们将它们合并成一个单独的“升级”脚本，并包含了任何已更改的存储过程“自上次以来”。
我们有一张表来存储最新补丁的版本号，因此升级工具可以应用任何更新的补丁。
每个存储过程都在单独的文件中。每个文件都以“插入”语句开始，向记录存储过程名称、版本和“现在”的日志表中插入数据。（实际上，是执行存储过程来存储这些数据，而不是原始的插入语句）。
有时，在部署过程中，我们会手动更改一个存储过程，或从DEV中发布其他内容，比较客户端测试和生产数据库上的日志可以让我们检查是否所有内容都处于同一版本。
我们还有一个“发布”主数据库，我们将更新应用到其中，并使用该数据库的恢复备份进行新安装（节省运行脚本所需的时间，这显然随着时间的推移而增加）。我们随时更新它，因为如果它有点陈旧，后续的补丁脚本就可以应用。
我们的发布数据库还包含经过消毒的初始数据（在新安装启动之前会被删除或有时被采用并修改-因此这不包含在任何更新脚本中）。
SQL Server 有一个工具栏按钮可以脚本化更改-所以您可以使用GUI工具进行所有更改，但是不要保存它们，而是生成一个脚本。（实际上，还有一个复选框可以始终生成脚本，因此如果您忘记只需按保存，它仍将在事后提供它使用的脚本，可以将其保存为补丁文件）
我们有一张表来存储最新补丁的版本号，因此升级工具可以应用任何更新的补丁。
每个存储过程都在单独的文件中。每个文件都以“插入”语句开始，向记录存储过程名称、版本和“现在”的日志表中插入数据。（实际上，是执行存储过程来存储这些数据，而不是原始的插入语句）。
有时，在部署过程中，我们会手动更改一个存储过程，或从DEV中发布其他内容，比较客户端测试和生产数据库上的日志可以让我们检查是否所有内容都处于同一版本。
我们还有一个“发布”主数据库，我们将更新应用到其中，并使用该数据库的恢复备份进行新安装（节省运行脚本所需的时间，这显然随着时间的推移而增加）。我们随时更新它，因为如果它有点陈旧，后续的补丁脚本就可以应用。
我们的发布数据库还包含经过消毒的初始数据（在新安装启动之前会被删除或有时被采用并修改-因此这不包含在任何更新脚本中）。
SQL Server 有一个工具栏按钮可以脚本化更改-所以您可以使用GUI工具进行所有更改，但是不要保存它们，而是生成一个脚本。（实际上，还有一个复选框可以始终生成脚本，因此如果您忘记只需按保存，它仍将在事后提供它使用的脚本，可以将其保存为补丁文件）
- Kristen
2
我正在考虑在数据库中添加一个SchemaVersion表，其中包含每个版本的记录。 SchemaVersion表的最后一个版本是数据库的当前级别。
我将创建（SQL）脚本，执行1.0的初始设置以及从1.0升级到1.1、1.1到1.2等操作。
即使是对于全新安装的1.2版本，也会运行所有这些脚本。这可能看起来有点慢，但只需要一次，在（几乎）空的数据库上完成。
这样做的最大优点是，全新安装将具有与升级安装相同的数据库架构。
正如我所说：我正在考虑这个问题。我可能明天开始实施这个方案。如果您感兴趣，我可以分享我的经验。我将为使用LINQ-to-entities和SQL Server以及MySQL作为DBMSes的c#应用程序实现此功能。
我很想听听其他人的建议和想法，如果有人能指出一个实现类似功能的开源.Net库或类，那就太好了。
编辑： 在 SO 上的一个不同 问题的答案 中，我找到了对 Migrator.Net 的参考。今天我开始使用它，看起来它正是我想要的。
我将创建（SQL）脚本，执行1.0的初始设置以及从1.0升级到1.1、1.1到1.2等操作。
即使是对于全新安装的1.2版本，也会运行所有这些脚本。这可能看起来有点慢，但只需要一次，在（几乎）空的数据库上完成。
这样做的最大优点是，全新安装将具有与升级安装相同的数据库架构。
正如我所说：我正在考虑这个问题。我可能明天开始实施这个方案。如果您感兴趣，我可以分享我的经验。我将为使用LINQ-to-entities和SQL Server以及MySQL作为DBMSes的c#应用程序实现此功能。
我很想听听其他人的建议和想法，如果有人能指出一个实现类似功能的开源.Net库或类，那就太好了。
编辑： 在 SO 上的一个不同 问题的答案 中，我找到了对 Migrator.Net 的参考。今天我开始使用它，看起来它正是我想要的。
- Jeroen Huinink
1
我认为最简单的方法是将例如从1.0升级到1.5的更新视为从1.0到1.1、1.1到1.2等一系列更新的连续进行。对于每个版本更改，请保留一个转换脚本/代码片段。
然后，在数据库中保留一个带有版本字段的表，并编译所需版本到应用程序中。在启动时，如果版本字段与编译的版本不匹配，则逐个运行所有必需的转换脚本。
理想情况下，转换脚本应该启动一个事务，并将新版本写入数据库作为提交事务之前的最后语句。
- unwesen
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
switch、case或match语句的语言中需要执行更复杂的转换操作，可以使用一系列的if语句：if(version==1) { something; version=2} if(version==2) { something; version=3}等等。 - undefined