数据库代码化(Database

  • 时间:
  • 浏览:3
  • 来源:大发彩神app—大发彩神8苹果版

下面对其进行说明:

1.每个数据库对应原本独立的目录,所含了该数据库的迁移脚本和配置信息。

2.数据库目录下的文件 flyway.conf 所含了该数据库的连接、认证、baseline 等信息。

3.子目录 base_sql 用于存放存量 schema,版本号格式为0.xxx。该目录中的内容选择后将不允许变更。

4.子目录 upgrade_legacy_private_cloud_sql 用于存放专有云老版本到新版本的迁移脚本,版本号格式为2.xxx

5.子目录 upgrade_sql 统一存放公有云和专有云的后续迁移脚本。是因为分析公有云并未编制版本,且专有云不同版本的编号最好的办法也处在差异,这里选择日期作为迁移脚本的版本前缀,格式为yyyy.mm.dd.index

6.不同环境的 DML 是因为分析处在差异。针对你这个 场景,也能 在迁移脚本中将差异累积用占位符表示,占位符的实际值由同名 properties 文件渲染得到,你这个V{yyyy.mm.dd.index}__xxx.properties。同名 properties 文件存上放去基线里,不同环境可设置不同的值,运行时会 将对应环境里的文件拷贝至 upgrade_sql 目录。

7.文件common/procedure.sql所含了变更 index、column、key 的存储过程,那些存储过程实现了变更的幂等性。

这里亲戚亲戚过后 人将数据库迁移脚本和应用代码存上放去相同的代码仓库里,并共享同原本 CICD 流程。你这个 模式最符合 DevOps 所倡导的相互相互合作、试验、快速反馈、持续改进等思想,能实现产品很快、更频繁、更稳定的交付。

Example:

Example:

Example:

Example:

Example:

在 state based 模式下,亲戚亲戚过后 人仅也能 维护数据库的目标情況。每个表、存储过程、视图、触发器都将保存为单独的 SQL 文件,那些文件将是数据库对象情況的真实表示。而升级数据库所需的脚本会由工具自动生成,从而大大减轻维护成本。

为了兼顾公有云和专有云,一齐考虑老版专有云的升级场景,亲戚亲戚过后 人设计了如下目录社会形态用于管理 SQL 迁移脚本。

Example:

Flyway 是一款开源的数据库迁移工具,它可不可以不能了方便地帮亲戚亲戚过后 人完成数据库的全新部署和增量升级。它有如下功能特点:

一般情況下,建议原本脚本只所含针对原本对象的一类操作。你这个,Vxxx_TB_car_add_column.sql代表为数据表car增加列,Vyyy_TB_car_insert.sql代表向数据表car中插入数据。你这个 模式符合单一职责的设计思想,可不可以不能了大大减少合并冲突的数量和僵化 性。

Example:

采用数据库代码化方案后,数据库的维护升级工作变得轻松简单。

Example:

理想情況下,每个迁移脚本只会在每个数据库上运行一次。但是因为分析某次迁移执行失败,很是因为分析也能 重新执行成功迁移的步骤也能使数据库恢复到理想情況。这时以等幂最好的办法编写迁移脚本将非常有帮助。这里亲戚亲戚过后 人总结了不同 DDL 和 DML 幂等性实现的最佳实践。

以修改表字段为例,这里将修改过程封装成了如下的存储过程。

Flyway 的工作原理如下:

本章将介绍 migrations based 模式下的代表性工具之一 Flyway,文中使用的版本为6.0.8

是因为分析亲戚亲戚过后 人不仅也能 避免 schema 的变更,还面临过后 数据迁移的场景,什么都有有有最终选择了 migrations based 模式,并使用 Flyway 帮助亲戚亲戚过后 人实现数据库代码化。

Example:

Example:

What we needed to do was to change our mindset of how we treated our database. We had to stop treating it like some special artifact or some unique scenario, and we started looking at it through the same perspective that we were treating our web code.

Example:

基于上述 SQL 迁移脚本的管理模式,公有云和专有云不同场景的执行流程如下表所示:

最近在做专有云输出时遇到了原本棘手的那些的什么的问题,客户也能 将亲戚亲戚过后 人两年前发布的版本升级到最新版。是因为分析跨度较长,产品代码和数据库 schema 都处在了巨大变化。产品代码累积是因为分析采用了版本管理策略,拥有明确的升级路径,但数据库累积是因为分析未采用代码化方案,是因为升级路径缺失,整个升级过程非常艰难。为了让过后的版本升级能顺利进行,也能 制定出一套统一的数据库代码化方案。

但你这个 模式不必能很好处在理数据迁移场景,你这个,将 user 表的 name 列拆分成 first name 和 last name 原本字段。这是因为分析数据表里的数据往往是上下文相关的,这是因为分析工具无法对数据进行可靠的假设以生成升级脚本。

State based 和 Migrations based 是来实现数据库代码化的两种常用最好的办法,下面分别进行介绍。

在 migrations based 模式下,亲戚亲戚过后 人也能 自行维护数据库从原本版本到原本 版本的变更脚本。相比 state based,该模式增加了维护的成本和僵化 性,但它能让亲戚亲戚过后 人更直接地控制迁移过程,从而也能避免诸如数据迁移原本 上下文相关的场景。过后 是因为分析变更通过命令式的最好的办法描述,亲戚亲戚过后 人可不可以不能了更早地对其进行评审。实现了 migration based 的代表性工具有 Liquibase、Flyway 等。