数据库迁移：单个创建脚本与更改集

Posted 2023-04-19

【中文标题】数据库迁移：单个创建脚本与更改集

【英文标题】：DB migration: Single creation script vs change sets

【发布时间】：2014-05-20 10:33:06

【问题描述】：

我正在为每个客户创建一个数据库架构。因此，每当有新客户注册时，我都需要在运行时快速创建他们的模式。

选项 1

在运行时，使用 Liquibase（或等效）运行所有变更集以生成最新架构。

缺点：

这很慢，可能有多个历史更改集 a 现在不再相关（创建表并在一年后删除它）。 这里在运行时使用 Liquibase，而不仅仅是“迁移时间”。不确定这是否是个好主意。 将 Liquibase 标准化作为创建模式的一种方式将迫使所有开发人员在开发过程中使用它。我们尽量避免向开发人员加载更多工具。

选项 2

每次构建后，我们都会使用 Liquibase 变更集生成一个临时数据库。然后从数据库中，我们基于当前快照创建一个干净的模式创建脚本。然后，当新客户到来时，我们只运行干净的脚本，而不是完整的变更集历史记录。

缺点：

下次我运行 liquibase 时，它​​将尝试从变更集 1 运行。解决方法可能是在生成脚本中包含变更集表的创建并将最新的变更集插入其中。 新模式是使用一个脚本创建的，而旧模式会经历变更集过程。从理论上讲，这可能会导致不同的模式。但是，单个脚本也经历了变更集过程，所以我想不出会导致错误的确切情况，目前这是一个理论上的问题。

你怎么看？

【参考方案1】：

为了保持一致性，我建议选项 #1。

数据库更新可能很复杂，变化的机会越少越好。这意味着您应该让您的开发人员最初创建 liquibase 变更集以更新他们的数据库，因为他们正在实施新功能以了解他们正在按预期运行，然后知道这些相同的步骤将在 QA 中一直运行到生产。这是他们需要处理的额外工具，但应该很容易以易于使用的方式集成到他们的标准工作流程中。

同样，我通常建议将不相关的历史变更集保留在您的变更日志中，因为如果您删除它们，您将偏离您已知的良好更新路径。数据库在大多数操作中都很快，尤其是在几乎没有数据的系统上。如果您有不再需要的特定变更集并且由于某种原因过于昂贵，您可以根据具体情况删除它们，但我建议很少这样做。

您是对的，从 liquibase 脚本创建数据库快照应该与运行 changeLog 相同——只要您在快照中包含 databasechangelog 表。但是，在生产过程中始终坚持实际的 Liquibase 更新将允许您使用上下文、前提条件和变更日志参数等功能，这些功能也可能对您的情况有所帮助。

【参考方案2】：

数据库部署有两种方法：

构建一次部署多次——这种方法使用与本机代码相同的原理，一次编译并跨环境复制二进制文件。从数据库的角度来看，这种方法意味着部署脚本生成一次，然后跨环境执行。

按需构建和部署 - 此方法在需要时生成增量脚本，以处理任何进程外更改。

如果您使用按需构建和部署方法，您可以为整个架构或工作项/变更集生成增量脚本。