这可能过于宽泛，但这是一个问题，我正处理一段时间。我们有一个应用程序，我们分发给我们的最终用户。它在德比后端运行。我们可以相当容易地推出代码更改，它将转到我们的服务器，看到有新版本，下载，覆盖旧代码，然后重新启动。
但是，当我们更改代码时，我们也会更改derby数据库的架构。我们没有很好的方法来更新它。目前我们可以通过FTP推送SQL更新。当程序连接到Internet时，它会查找新的SQL文件，下载并运行。
不幸的是，很多客户的互联网访问受限，所以他们会间歇性地获得这些更新。有时因为它们的变化足够大，它们的本地数据库模式与我们想要的不同步。或者他们通过CD获得代码更改，但不是SQL更改（有人将其邮寄给CD）。
我一直在尝试创建一个可以提供模式的XML表示的SOAP服务。到目前为止，它一直是一个巨大的PITA。
人们目前使用哪些方法来维护这样的数据库？我觉得我不是第一个这样做的人，所以可能有比我正在做的更好的方式。
根据这里的一些评论，这是一个更新： 基本上，我认为我们很早就没有坚持严格的数据库版本，所以我不知道每个人的数据库是怎么回事。很多人都有自定义安装（随意呻吟）。我需要一个可以分辨他们的数据库和“官方”副本之间差异的工具。
我有一个工具，它有点工作，但是有很多......需要跟踪的东西。
答案 0 :(得分：3)
您可以将代码更改作为代码更改的一部分进行分发吗？然后，当应用程序重新启动时，它会检查是否需要在数据库上运行任何更新。
显然，您需要对数据库架构进行版本控制，以避免多次应用同一更新。
我知道有些应用程序可以执行此操作（主要使用Ruby，但也使用Java）。
答案 1 :(得分：2)
如果您的应用程序中已经有可以下载程序以更改已安装的源代码的更新机制，那么为什么不将该架构更改打包并运行作为升级过程的一部分？我只是将更新作为Java应用程序的一部分运行。
我的团队正在使用MyBatis Migration tool来处理这些更改，{{3}}将每个架构更改表示为包含“make change”和“rollback”步骤的单个迁移脚本。 changelog表存储在数据库中，该表列出了已应用于该数据库的更新，这使migrate命令可以轻松确定运行时需要应用哪些更新。这个特定工具可能仅在您控制数据库并且能够运行shell命令和脚本来更改数据库时非常有用，但您可以在方法中使用相同的概念 - 将每个模式更改打包为原子单元并运行它们从您的程序中将架构带到当前版本，您可以在db本身中跟踪它。
答案 2 :(得分：0)
您需要一个包含用户正在运行的数据库版本的表，然后您需要代码从版本n升级到版本n + 1。假设您有一个可以访问架构更改的数据库用户，您可以像应用代码更改一样应用架构更改。