编纂数据库架构更改（也称为架构迁移）的想法并不新鲜。许多工程团队都采用了液基基地/飞行路线来采用这种做法。与此同时，我们观察到整个行业采用数据库即代码（DaC）的加速趋势。一些创新产品也出现了，以挑战现有企业。
在这篇博客中，我们将回顾数据库作为代码环境中的最新技术，并分享我们自己对该领域当前和未来趋势的见解。
概述
Liquibase
Liquibase成立于2006年，可以说是这一领域最知名的产品。当有人在论坛上请求数据库模式更改建议时，您通常会看到一个提到Liquibase的回复。
Liquibase既是一个开源项目，也是一家提供商业产品的公司。该公司曾被称为Datical，并更名为Liquibase以巩固品牌（明智之举）。Liquibase的主要产品是基于Java的CLI。通过CLI，开发人员团队可以将数据库模式迁移集成到其CI/CD工作流中。对于Java应用程序，Liquibase也可以用作库。应用程序通常嵌入Liquibase库，以便在启动时应用任何适用的模式迁移。
在Liquibase中，模式迁移单元封装在Change Set。可能是因为它的年代久远，而且是Java的根，所以最常用的形式是XML（稍后添加了YAML和JSON支持）：
普通SQL也支持适当的注释：
Liquibase是基于迁移。它记录目标数据库架构的增量更改，而不是所需的结束状态。
最近，Liquibase推出了HUB，这是一个面向付费客户实时查看、组织和监控数据库更改活动的信息门户。
Flyway
Flyway在许多方面与Liquibase相似。这是一个有着悠久历史和庞大客户群的开源项目。它的核心产品包括CLI和Java库。Flyway最近还发布了一个名为Hub的门户网站。
Flyway背后的商业实体是通过收购Redgate。品牌化可能会引起一些混淆，同时也会在开源和商业产品之间设置界限。Flyway的品牌基调更为随意：
Flyway网站并不像那个些使用复杂渐变的新开发工具公司那个样耀眼。您甚至可以发现一些基本的UI间距问题。然而Flyway展示了一个经典的例子，内容比美容更重要，它的文档因为清晰而引人注目。
Liquibase和Flyway并驾齐驱。主要区别在于各自的定位。Liquibase服务于企业客户，而Flyway则更易于开发人员访问。
Sqitch
Sqitch也是一个开源项目，已经上市一段时间了。Sqitch完全基于CLI，没有UI。与基于Java的Liquibase/Flyway不同，Sqitch是用Perl开发的。
选择Perl并不是唯一有趣的方面。关于如何管理数据库模式更改，Sqitch有自己的设计理念。Liquibase和Flyway都使用文件命名约定来控制架构迁移行为（约定优先于配置）：
而Sqitch采用了一种显式的方法。在下面的示例中，需要将模式迁移命名为appschema :
如果以后要应用另一个迁移，则取决于appschema，您需要提供–需要 :
Sqitch还为schema变更部署提供了惟一的tag和bundle命令，这为团队提供了将模式部署连接到应用程序开发生命周期中的更多权力。
德佐恩 >数据库区域 >数据库作为代码环境
数据库作为代码环境
从基准模式迁移工具到包含“数据库即代码”思想的新产品，让我们来分析当前的情况并探索趋势。
Tianzhou Chen user avatar通过陈天洲 · 7月24日、22日 ·数据库区域 ·意见
Like(1)评论(0)
Save推特386万意见
加入DZone社区，获得完整的会员体验。免费加入
这是关于数据库即代码（GitOps）系列文章的一部分：
数据库作为代码：好的，坏的，丑陋的
数据库版本控制：基于状态还是基于迁移？
什么是数据库模式漂移？
数据库作为代码环境（这一个）
对数据库模式更改进行编码（也称为模式迁移）的想法并不新鲜。许多工程团队已雇用Liquibase/Flyway采用这种做法。同时，我们也看到了拥抱的加速趋势数据库作为代码（DaC）整个行业。一些创新产品也出现了，以挑战现有企业。
在本博客中，我们将回顾数据库中代码景观的最新进展，并分享我们对该领域当前和未来趋势的见解。
概述
看门人
利基酶
Liquibase成立于2006年，可以说是这一领域最知名的产品。当有人在论坛上请求数据库模式更改建议时，您通常会看到一个提到Liquibase的回复。
Liquibase既是一个开源项目，也是一家提供商业产品的公司。该公司曾被称为Datical，并更名为Liquibase以巩固品牌（明智之举）。Liquibase的主要产品是基于Java的CLI。通过CLI，开发人员团队可以将数据库模式迁移集成到其CI/CD工作流中。对于Java应用程序，Liquibase也可以用作库。应用程序通常嵌入Liquibase库，以便在启动时应用任何适用的模式迁移。
在Liquibase中，模式迁移单元封装在Change Set。可能是因为它的年代久远，而且是Java的根，所以最常用的形式是XML（稍后添加了YAML和JSON支持）：
普通SQL也支持适当的注释：
利基巴斯是基于迁移。它记录目标数据库架构的增量更改，而不是所需的结束状态。
最近，Liquibase推出了HUB，这是一个面向付费客户实时查看、组织和监控数据库更改活动的信息门户。
飞机道
Flyway在许多方面与Liquibase相似。这是一个有着悠久历史和庞大客户群的开源项目。它的核心产品包括CLI和Java库。Flyway最近还发布了一个名为Hub的门户网站。
Flyway背后的商业实体是通过收购Redgate。品牌化可能会引起一些混淆，同时也会在开源和商业产品之间设置界限。Flyway的品牌基调更为随意：
Flyway网站并不像那个些使用复杂渐变的新开发工具公司那个样耀眼。您甚至可以发现一些基本的UI间距问题。然而Flyway展示了一个经典的例子，内容比美容更重要，它的文档因为清晰而引人注目。
Liquibase和Flyway并驾齐驱。主要区别在于各自的定位。Liquibase服务于企业客户，而Flyway则更易于开发人员访问。
斯基奇
Sqitch也是一个开源项目，已经上市一段时间了。Sqitch完全基于CLI，没有UI。与基于Java的Liquibase/Flyway不同，Sqitch是用Perl开发的。
选择Perl并不是唯一有趣的方面。关于如何管理数据库模式更改，Sqitch有自己的设计理念。Liquibase和Flyway都使用文件命名约定来控制架构迁移行为（约定优先于配置）：
而Sqitch采用了一种显式的方法。在下面的示例中，需要将模式迁移命名为appschema :
如果以后要应用另一个迁移，则取决于appschema，您需要提供–需要 :
Sqitch还为schema变更部署提供了惟一的tag和bundle命令，这为团队提供了将模式部署连接到应用程序开发生命周期中的更多权力。
Atlas
Atlas是最近推出的一种新的数据库模式迁移工具。它从现有工具中提取特征：
它类似于Liquibase/Flyway/Sqitch，因为它主要关注CLI，尽管它也有一个轻量级的UI来可视化模式。
它类似于Prisma，因为它设计自己的领域特定语言（DSL）来定义数据库模式。最初，它选择与Prisma相同的基于状态的方法，但是看起来它还添加了基于迁移的方法。
它也深受HashiCorp Terraform的影响，使用Go并发明了自己的DSL。它们甚至在Hacker News上首次作为数据库迁移的Terraform出现
Altas当前的焦点是CLI。在与现有的CLI工具（如Liquibase/Flyway）进行比较时，它的优势在于采用了现代编程语言（Go而不是Java），并从Terraform和Prisma等工具中学习。
ORMs公司
数据库模式迁移是应用程序开发不可或缺的一部分；因此，流行的应用程序框架和orm提供了内置的模式迁移功能就不足为奇了：
rubyonrails活动记录迁移（Ruby）
Django迁移（Python）
Mybatis迁移（Java）
戈姆迁移（Go）
尽管数据库模式迁移属于后端范畴，但最新的创新来自Prisma，一个具有前端根的ORM。
Prisma
节点。js为前端工程师开发全栈应用程序打开潘多拉盒子。我们称之为潘多拉之盒，因为它既带来繁荣，也带来混乱。全套应用程序由三部分组成：
代码（无状态部分）
数据（状态部分）
以及代码如何与数据交互
对于一个典型的希望构建一个可持续的全栈应用程序的前端工程师来说，TypeScript/Express。js正在解决代码问题。像MongoDB这样的NoSQL数据库正在解决数据问题。Prisma的目标是最后一个用数据连接代码的问题。
对于前端工程师来说，可用性和可访问性尤为重要。像素是用来构成和不完美的SQL。为了降低管理数据库模式的障碍，Prisma专门设计了DSL：
DSL采用基于状态的方法（声明性的），因为DSL描述目标数据库模式的期望结束状态，而不是增量更改。这与Liquibase/Flyway/Squitch不同。
Prisma还在集成和开发工作流方面投入了大量资金。
与它的后端ORM同级不同，Prisma采用了一种全新的方法，并提供了在整个应用程序开发生命周期中管理数据库数据和模式的更全面的视图。
通过查看他们的产品线，你可以很容易地看出他们的雄心壮志绝不局限于成为一个ORM和模式迁移工具。
上面描述的所有工具都可以用于许多不同的数据库系统。虽然数据库作为代码的应用是数据库不可知的，但是出现了新的数据库系统来提升开发人员的体验作为一个关键的区别。这种以开发人员为中心的视角以及分支/克隆等特性与数据库代码背后的思维方式相一致。
PlanetScale
PlanetScale曾经是一个Vitess托管服务。他们去年开始关注开发人员的工作流程。尽管您可能仍然会在他们的网站上看到一些Vitess的足迹，但大多数新材料都在讨论数据库开发工作流功能，例如分支、在线模式更改和最近引入的回放：
当我们在上面介绍Prisma时，我们提到了构成完整堆栈应用程序的三个支柱：
代码（无状态部分）
数据（状态部分）
以及代码如何与数据交互
对于数据部分，MongoDB是一个流行的选择。人们选择它是因为它的可用性，而不是无处不在。对于承载关键应用程序数据（如用户信息、客户订单和帐单），您仍然需要一个基于SQL的关系数据库。PlanetScale基于MySQL，通过Vitess的可伸缩性进行了增强，并由出色的PlanetScale产品团队针对可用性进行了精心设计。这是一个吸引人的选择。它似乎结合了两者的优点，保留了SQL数据库的所有优点，同时又不牺牲开发人员的经验。
Neon
Neon是刚刚发布的另一个开源数据库。
在较高的层次上，它与PlanetScale有很多相似之处：无服务器、开发人员生产力、完全管理。
主要区别在于技术组合：
Neon位于PostgreSQL阵营，而PlanetScale则基于MySQL。
PlanetScale利用Vitess提供其高级数据库功能，而Vitess本身是MySQL服务器节点上的一个中间件。Neon采用了一种更激进的方法来构建一个专用的存储层来提供这些所需的功能。
Neon可以有更高的电势，因为它对整个堆栈有更好的控制。这将是非常有趣的，看看Neon是如何发展与PlanetScale。MySQL和PostgreSQL之间的爱恨关系是永无止境的，从vanilla MySQL vs PostgreSQL，分布式数据库TiDB ，云数据库AWS Aurora vs GCP AlloyDB，再到以开发者为中心的数据库PlanetScale对Neon。
Dolt
Dolt是独一无二的。该网站将其描述为具有类似Git的版本控制的数据库系统。
Dolt与其他数据库系统截然不同，因为它构建了一个内置Git语义的引擎。这是把双刃剑。一方面，它带来了所需的Git属性，另一方面，它给优化典型的OLTP工作负载带来了挑战。
Dolt采取了一个更大胆的行动，采用数据库作为代码，因为它模糊了数据库和代码之间的界限。它目前的定位是将Git语义引入数据库。另一种方法是否也可以，甚至更好地将数据库语义引入Git？毕竟，许多应用程序已经使用Git作为唯一的数据存储。
Bytebase
Bytebase是一个开源项目，始于2021年1月。它还与上述产品有一些共同的特点：
与Liquibase/Flyway/Sqitch一样，Bytebase提供了一个名为bb的CLI，并使用基于迁移的方法来应用数据库模式更改。
与Prisma一样，Bytebase提供了一个完整的webui来执行数据库开发活动（模式、数据更改、SQL查询）。
和Atlas一样，Bytebase使用了一个现代的技术栈，使用Go而不是Java。
与PlanetScale/Neon一样，Bytebase注重开发人员体验。VCS集成就是一个例子：Bytebase提供了一个点击式向导来配置VCS（类似于您在Vercel/Netlify中找到的链接代码库的经验）：是一个开源项目，始于2021年1月。它还与上述产品有一些共同的特点：
与Liquibase/Flyway/Sqitch一样，Bytebase提供了一个名为bb的CLI，并使用基于迁移的方法来应用数据库模式更改。
与Prisma一样，Bytebase提供了一个完整的webui来执行数据库开发活动（模式、数据更改、SQL查询）。
和Atlas一样，Bytebase使用了一个现代的技术栈，使用Go而不是Java。
与PlanetScale/Neon一样，Bytebase注重开发人员体验。VCS集成就是一个例子：Bytebase提供了一个点击式向导来配置VCS（类似于您在Vercel/Netlify中找到的链接代码库的经验）：
Bytebase是一个多面手，具有团队协作功能：
一个独立的开发团队可以托管一个Bytebase实例来管理数据库开发活动。
DBA或平台团队还可以托管一个Bytebase实例，供整个组织中的所有产品团队使用。
它具有本机VCS集成，以简化代码和数据库开发。Bytebase有项目和问题这样的概念，因为它类似于Jira和GitLab/GitHub等系统。
它也有概念Tenant 和环境管理跨多个环境的多租户应用程序的数据库更改。
Bytebase提供了内置的模式审查策略，以在整个工程组织中强制实施模式标准。
Bytebase被设想为GitLab/GitHub的对应物来管理数据库开发方面。它被定位为团队协作的数据库DevOps解决方案。
Bytebase与其他工具的比较：
总结
虽然数据库作为代码的想法并不新鲜，但在过去两年里，这一趋势加快了：
像GitLab和GitHub这样的商业公司一直在大力投资基于Git的DevOps基础设施。
像HashiCorp这样的商业公司利用Git基础设施，开发像Terraform这样的创新产品。Terraform的成功反过来推广了GitOps工作流，并将行业思维从点击式系统转变为基于代码的系统。
开源生态系统正在扩散。巧合的是，这个领域中的所有产品要么是开源项目，要么是它们的衍生产品。
创造了新的挑战现状：
v8javascript引擎和节点的发明。js为前端工程师直接与数据库交互打开了大门。大量的前端工程师对开发人员的经验要求很高。
由于其务实的设计和驾驭云计算的浪潮，Go已经成为主流语言。它挑战了使用Java构建后端应用程序的常识。尤其是在云计算时代，围棋占据了市场的主导地位。为了部署基于Java的程序，需要首先安装JVM，而Go不需要这样做。只要采用Go，像Bytebase和Atlas这样的工具就可以在与Liquibase/Flyway相比时获得竞争优势，更不用说语言本身所带来的开发人员生产力的提升。
尽管数据库市场非常成熟，但市场利润丰厚，不容忽视。成为下一个雪花是每个数据库从业者的梦想。建立了新的数据库系统，门槛越来越高。核心数据库的能力和性能只是表的赌注，为了区别对待，它们必须竞争开发人员的经验。
标志性文章”进化数据库设计”写于2016年，虽然“数据库即代码”一词并没有在那里被创造出来，但那篇文章总结了十年前将数据库作为代码实践所积累的智慧。
本文还预测了一个趋势，即规模庞大的DBA团队将变得不那么普遍。如今，许多严肃的工程团队仍然需要DBA的专业知识；同时，与数据库的交互也成为开发人员的日常工作。
随着时间的推移，管理数据库开发的动力已经发生了变化，对更好的开发人员体验和高效的开发人员工作流程的要求也越来越高。
它需要数据库系统、数据库工具和行业思维之间的微妙舞蹈来征服它。数据库即代码是一个关键的难题，在这个领域构建时间是再好不过的了。
原文标题：The Database as Code Landscape
原文作者：Tianzhou Chen
原文地址：https://dzone.com/articles/the-database-as-code-landscape
