1

这可能太宽泛了，但这是我不得不花时间处理的一个问题。我们有一个分发给最终用户的应用程序。它运行在德比后端之上。我们可以相当轻松地推出代码更改，它会发送到我们的服务器，查看有新版本，下载，覆盖旧代码，然后重新启动。

但是，当我们更改代码时，我们也会更改 derby 数据库的模式。我们没有很好的方法来更新它。目前我们可以通过 FTP 推送 SQL 更新。当程序连接到 Internet 时，它会查找新的 SQL 文件，下载并运行它们。

不幸的是，我们的许多客户的互联网访问受限，因此他们会间歇性地获得这些更新。有时因为它们的变化足够大，它们的本地数据库模式与我们想要的不同步。或者他们通过 CD 获得代码更改，而不是 SQL 更改（有人将 CD 邮寄给他们）。

我一直在尝试做的是创建一个 SOAP 服务，它可以提供模式的 XML 表示。到目前为止，这是一个巨大的 PITA。

人们目前使用哪些方法来维护这样的数据库？我觉得我不是第一个这样做的人，所以可能有比我正在做的更好的方法。

根据这里的一些评论，这里有一个更新： 基本上，我认为我们很早就搞砸了，因为我们没有遵守严格的数据库版本控制，所以我不知道每个人的数据库情况如何。很多人都建立了自定义安装（随意呻吟）。我需要一个工具来区分他们的数据库和“官方”副本之间的差异。

我有一个工具，它有点工作，但有这么多……很多……要跟踪的东西。

4

3 回答 3

3

您可以将数据库更改作为代码更改的一部分进行分发吗？然后，当应用重新启动时，它会检查是否需要在数据库上运行任何更新。

显然，您需要对 DB 模式进行版本化以避免多次应用相同的更新。

我知道一些执行此操作的应用程序（主要是在 Ruby 中，但也在 Java 中）。

于 2012-08-03T15:56:11.060 回答
2

如果您的应用程序中已经有了更新机制，可以下载程序来更改已安装的源代码，为什么不打包并运行架构更改作为升级过程的一部分呢？那时我只是将更新作为 Java 应用程序的一部分运行。

我的团队使用MyBatis 迁移工具来处理这些更改，该工具将每个模式更改表示为一个包含“进行更改”和“回滚”步骤的迁移脚本。数据库中存储了一个changelog表，其中列出了哪些更新已应用于该数据库，这使得migrate命令可以轻松确定在运行时需要应用哪些更新。这个特定工具可能仅在您控制数据库并能够运行 shell 命令和脚本来更改数据库时才真正有用，但您可以在您的方法中使用相同的概念 - 将每个模式更改打包为一个原子单元并运行它们从您的程序中将架构升级到当前版本，您可以在数据库本身中对其进行跟踪。

于 2012-08-03T15:57:45.397 回答
0

您将需要一个包含用户正在运行的数据库版本的表，然后您需要从版本 n 升级到版本 n+1 的代码。假设您有一个有权进行架构更改的数据库用户，您可以像现在应用代码更改一样应用架构更改。

于 2012-08-03T15:57:10.420 回答