sql - 将架构更新推送到最终用户数据库的一些好方法是什么？

Question

这可能太宽泛了，但这是一个让我费了好大劲才处理的问题。我们有一个分发给最终用户的应用程序。它在 Derby 后端之上运行。我们可以很容易地推出代码更改，它会发送到我们的服务器，查看是否有新版本，下载，覆盖旧代码，然后重新启动。

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

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

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

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

根据此处的一些评论，更新如下:基本上，我认为我们很早就没有遵守严格的数据库版本控制，所以我不知道每个人的数据库情况如何。很多人都构建了自定义安装(随意提示)。我需要一个工具来区分他们的数据库和“官方”副本。

我构建了一个工具，它有点用，但是有那么多……很多……事情需要跟踪。

Answer 1

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

显然，您需要对数据库模式进行版本控制以避免多次应用相同的更新。

我知道一些执行此操作的应用程序(主要是 Ruby，但也有 Java)。