为什么以及何时使用Liquibase？

Question

我在stack overflow上搜寻了这个问题，但是没有找到有关此的任何问题。

我是Liquibase的新手，想要学习:

• 为什么要使用Liquibase？
• 在项目中应该在什么情况下使用Liquibase？

我知道这是为了将所有数据库更改保存在一个地方，但是可以通过在某些存储库系统中创建简单的SQL文件并随时间更新来完成类似的操作。

- SSC

Answer 1

自管理模式创建文件和Liquibase（或其他模式迁移工具）之间的关键区别在于后者提供了模式更改日志。这是一份记录模式变化的时间表。它允许数据库设计师指定模式中的更改，并在需要时启用编程升级或降级模式。

还有其他好处，例如：

• 数据库供应商独立性（这是有争议的，但他们尝试着实现）
• 自动文档化
• 数据库模式差异

另一个替代工具是flyway。

当你想要或需要自动管理模式更新而不丢失数据时，你会选择使用模式迁移工具。也就是说，你期望在部署到长期运行的环境（如客户现场或稳定测试环境）后模式会发生变化。

- Synesso

---

但是假设我们创建了一个文件并在其中编写了我们的第一个脚本，并将其提交到Git。现在，随着时间的推移，模式将被更新，我们可以回到任何时间间隔并将模式改回来，不是吗？ - SSC

通过这种方法，您可以重新创建模式，但无法降级/升级。区别在于数据的丢失。 - Synesso

但是另一部分，什么时候使用却不明确？ - SSC

Synesso，我还没有看到如何在生产数据库使用一段时间并且已经根据数据做出决策后自动降级。现在您不一定可以将它们删除。此外，我不明白为什么这比只是在源代码控制中保留一系列版本化的SQL脚本更好，这些脚本包括从头开始插入版本表格和最后更新它以跟踪已应用的内容。 - Khorkrak

另外一个问题是，我们如何在Java中通过电子邮件记录SQL通过XML进行更改时的错误？ - UmaShankar

Answer 2

我看到liquibase在修改模式时可以让开发人员遵循规范。你不能直接覆盖其他开发人员的更改并执行。相反，你需要创建自己的changeset并将其添加到要执行的变更序列的末尾。这还可以清楚地了解每个更改是何时发生以及由谁引入。

这是一种非常“版本化”的模式维护方法。

对于初学者来说，这似乎会增加“不必要的工作”。

- iCrus

---

这就是我（它给了我你提到的确切印象 :P）+1 对于那个关键决定。 - Ismail Sahin

你说得对，我们可以跟踪所有更改，了解最新更改的人和时间。如果我们需要回滚到特定点，Liquibase会很有帮助。 - Anoop P S

Answer 3

如果你在开发、质量保证和生产中有多个数据库实例，并且希望有一个工具可以自动跟踪更改历史并智能地应用更改（应用当前模式和最终模式的差异），那么像Liquibase或Flyway这样的工具将非常有用。

- Ted Xu

Answer 4

我认为如果您阅读以下文章，就可以回答为什么Liquibase会被使用。请参考此链接：http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html 如果您仔细阅读该文章，您会发现通过简单的mvn或CLI命令从高版本降级到低版本的能力非常有用，如果您选择将SQL文件提交到GIT中，则无法获得这种能力，因为那样则必须手动运行这些脚本，同时您也不会有像更改集（例如：谁进行了更改、作者等）这样的信息。

- Shikhar Chaudhary

Answer 5

我认为Liquibase在你的哲学是数据库是一个后置考虑时非常好用。这种哲学导致了大多数生产中的糟糕数据库，其中大部分都很糟糕。数据库应该以完整的业务系统视图来设计，而不是由各个应用程序开发人员在自己的隔间里逐个设计。后一种方法会导致解决方法、非规范化数据、表之间的关系不良、业务领域重复以及总体混乱的高维护成本系统，客户在部署后不久就会因其引起的问题而讨厌它。如果数据库被设计为准确反映业务关系，则其寿命将比像大多数数据库那样以拼凑的方式设计的长5倍，并且将比后者更好地服务于其目的。

Liquibase本身并不是问题，但它使应用程序开发人员设计数据库成为可能，这才是问题所在。

- Bob Barry

---

规格变化，新功能被添加，错误得到修复。即使假设“数据库被设计为准确反映商业关系”，随着时间的推移，您需要对数据库进行更改是很正常和预期的，因为企业和商业关系会随时间而变化。Liquibase只是帮助您管理这些变化。就是这样。 - Steven Byks

根据我的经验，很少有DBA和大量的开发人员使用Liquibase - 我认为@bob-barry在大多数最终结果上是正确的。然而，使用像Liquibase这样的工具（或者只是普通的git来记录更改历史）的DBA会发现它非常有用。 - keba

进化的数据库实践和敏捷开发一般鼓励并使同行评审成为可能。对于需要高性能的数据库，DBA 仍然与应用程序团队合作进行数据库更改。像 Liquibase 这样的工具可以更轻松地进行重构，与您的去规范化论点相悖。10 年前，我曾为一个在 20 多个客户端安装的产品工作，每个客户端都有自己的补丁和升级周期。经历了两年的噩梦，并试图手动编写这样的工具后，我们一旦了解到 Liquibase 就立即采用了它。而我们的表格中有 2 亿条记录，虽然对于当时来说不算太大，但需要 DBA 来处理。 - user6317694

希望有一天能在天堂见到你，听起来很美好。 - Bijan

软件不应该是僵化的；企业总是在不断发展，软件应该适应不断变化的需求。因此，我们经常需要对数据库模式进行更改，而这类工具能够帮助我们有效地管理这些变化。 - undefined

Answer 6

作为团队中的DevOps人员，我更喜欢将所有SQL文件放在一个地方，即我的SCM（源代码管理）中。

此外，在CI/CD阶段，如果DB模式随之创建，可以节省大量时间和资源。您不必再为该客户管理数据库。

像Flyway、Liquibase、EF等ORM有助于实现这一目标。

- Sloka Roy

---

Flyway和Liquibase不是对象关系映射器，而EF是。 - Yehuda Makarov

Answer 7

我认为在这个话题中加入进化式数据库设计的概念是很好的。

在过去的十年中，我们开发和完善了许多技术，使得数据库设计可以随着应用程序的开发而不断演变。这对于敏捷方法来说是非常重要的能力。这些技术依赖于将持续集成和自动化重构应用于数据库开发，并与数据库管理员和应用程序开发人员之间的紧密协作相结合。这些技术适用于预生产和发布系统，在绿地项目以及遗留系统中都可以使用。

这里是Martin Fowler的进化式数据库设计https://martinfowler.com/articles/evodb.html的参考资料。

这是一种不同的创建数据库设计的方法，这就是Liquibase和Flyway的原因。

- grojas123

Answer 8

在观察了Liquibase被合并到一个中大型项目中的许多月后，我提出这样的观察：开发人员必须为Liquibase服务，而不是相反。我理解使用情况，但没有看到我们的开发过程有任何定性的改进。我们的现实是，Liquibase给我们的开发团队带来了构建错误等问题。小的更改会带来很大的麻烦。我尊重地不建议使用它。

- Brett Shelley

---

欢迎来到 Stack Overflow，请在此处参观 https://stackoverflow.com/tour 并阅读帮助中心以提供最佳反馈。 - Amirhossein