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

Question

我正在为每个客户创建一个数据库模式。所以，无论何时注册新客户，我都需要在运行时快速创建模式。

选项1

在运行时，使用Liquibase（或同等）运行所有的变更生成最新的模式。

缺点：

• 这是缓慢的，也可以是多个历史变迁setsa现在是不相关的话（create table和一年后放弃它）。
• Liquibase在运行时用于此处，而不仅仅是“迁移时间”。不知道这是不是一个好主意。
• 将Liquibase作为构建模式的一种手段，将迫使所有开发人员在开发过程中使用它。我们尽量避免向开发人员加载更多工具。

选项2

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

缺点：

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

您怎么看？

Answer 1

我会建议选项＃1的一致性。

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

同样，我通常建议在changeLog中留下不相关的历史changeSet，因为如果删除它们，您将偏离已知的更新路径。数据库对于大多数操作来说是快速的，特别是在数据很少或没有数据的系统上。如果您有特定的changeSets不再需要，并且由于某种原因过于昂贵，您可以根据具体情况将其删除，但我会建议这样做很少。

如果您在快照中包含数据库更新日志表，那么从liquibase脚本创建数据库快照应该与运行changelog相同。但是，坚持使用实际的Liquibase更新到生产将允许您使用上下文，前提条件和更改日志参数等功能，这些参数可能对您的案例有所帮助。

Answer 2

有数据库部署两种方法：

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

2. 构建&按需部署 - 此方法在需要时会生成增量脚本，以处理任何过程更改。

如果您使用生成&部署按需方法，您可以生成整个架构或工作项目/变更三角洲脚本。