已部署的 Web 应用程序中数据库更改的最佳实践答案

【问题标题】：Best practices in database changes in web applications already deployed已部署的 Web 应用程序中数据库更改的最佳实践
【发布时间】：2012-04-05 08:18:20
【问题描述】：

我正在尝试找到解决以下问题的标准方法。
我在容器（特别是 Tomcat）中部署了一个 Web 应用程序，它使用数据库来实现其功能（在我的情况下，它是文件模式的 SQL 数据库，因此没有后端 SQL 服务器）。

我感兴趣的是，随着数据库架构的变化（新表/新列、删除列等），在较新版本的 Web 应用程序上处理我的数据库的各种更改的最佳方法是什么。
IE。我该如何处理有人升级到我的 Web 应用程序的较新版本，并且仍然以最佳（自动？无缝？少手动？）方式保留旧数据库中的旧数据。

我认为这不是一个罕见的情况，所以我相信我可以在这里遵循一些最佳实践。
谁能帮我解决这个问题？

【问题讨论】：

【解决方案1】：

最近我们发现了Flyway - 它运行良好，并且包含数据库架构更改的版本控制（纯 SQL 脚本）。

显然这个话题要广泛得多。例如，当应用程序的新旧版本都应该在更新的模式中完美运行时，您需要格外小心。您还应该考虑回滚策略（当升级效果不佳或您想降级应用程序时） - 有时就像删除添加的对象（表、列）一样简单，但是当您的脚本删除一些东西，回滚应该恢复它们。

【讨论】：

【解决方案2】：

首先，您希望尽可能少地更改数据库，尤其是现有列。

其次，如果您需要重命名列或更改某些约束（注意不要变得更严格，因为可能会有一些不匹配的数据），请使用ALTER TABLE 语句。这样，除非您删除列，否则列中的数据将被保留。 :)

此外，为具有约束的新列提供默认值（例如 not null），因为该表中可能已经存在需要更新的数据集，以免违反这些约束。（或者添加列，运行一些代码来填充列，然后添加约束。）

第三，由于您的应用程序似乎有多个用户并且他们可能有不同的版本，提供更新的最简单方法是提供对下一个更高版本的顺序更新。因此，如果有人想从版本 2 更新到 5，您首先要进行 2->3 更新，然后是 3->4，最后是 4->5。

这可能需要更长的时间才能运行，但应该会降低复杂性，因为您的机器人必须担心所有可能的组合（例如 2->4、2->5、3->5 等）

【讨论】：

但是升级过程应该如何处理这个问题？例如。如果我的应用程序通过 RPM 交付并且我的数据库是文件对象 SQL 数据库脚本应该如何/何时运行？我无法获得整体设计
@Jim 我知道的应用程序有一个单独的更新过程，您通常手动启用它并在运行后自行禁用。如果您有 RPM 分发，则应用程序可能会默认启用更新，并且在启动或第一次运行期间，如果启用，更新过程将由应用程序运行。更新成功后，会设置一个标志以在后续启动期间禁用更新（除非在这期间再次发生 RPM 更新）。