关系型数据的迁移与版本控制
目录
数据库迁移与版本控制
所谓数据库迁移（Migration）就是数据库表结构的演变，更多的是一种 “演进”。而数据库版本控制（Version Control）则包含更多，包括：Version Track（版本跟踪）、Upgrade（升级）、Downgrade（降级）、BACKUP（备份）、原子性操作等。从术语上，我们通常使用 Migration 来概括界限模糊的两者，本质是一种 “内容版本控制系统”，就像 Git 一般。
数据库迁移的方式大体上有两种：
- 基于原生 SQL 的迁移。
- 基于 ORM Schema 的迁移。
前者因为和上层应用逻辑耦合度较低，从 DBA 的视角出发，所以可以直接基于 SQL 语句来完成，主要关注的是数据记录安全备份、恢复、跨平台兼容等场景；而后者主要服务于生产级应用程序，从 Developer 的角度出发，是随着应用程序版本迭代而进行的 ORM Schema 更新。
如果你在应用开发的过程中，需要频繁地通告开发团队成员切记手动维护本地数据库表结构，继而维护开发环境，尤其在分布式协作团队当中（例如：开源社区），那么这正是 ORM Schema Version Control 所致力于解决的问题 —— 提供实时的数据库版本升级。
DB Migration 的本质是 DDL
DDL（数据定义语言）用于创建数据库中的各种对象，例如：表、视图、索引、同义词、聚簇等，对应的指令为：CREATE TABLE、VIEW、INDEX、SYN、CLUSTER 等。
需要注意的是，DDL 操作在 RDBMS 层面是隐性提交的，不能 Rollback，但数据库应用程序可以显示的执行 “删除/还原” 实现 Rollback 的效果。
为什么需要 DB Migration？
数据库应用软件的版本迭代过程中难免需要修改 ORM 的数据模型（Data Model）即 DLL，例如：添加一个表、添加一个字段、修改一个字段的属性等。
然而在生产环境中，这些 DDL 操作不可以影响到现存的生成数据记录。这里就会出现一个需求：怎样在保证原有生产数据完整性的情况下对数据库进行升级，或回滚到之前的某一个时刻以复现环境，这就是需要 DB Migration 的核心述求。
参见《Openstack_SQLAlchemy 修改数据库的表结构》一文。
常见的 DB Migration
Alembic
在 Python 生态中，SQLAlchemy 是一款非常优秀的 ORM 框架，但其本身没有提供数据库版本控制功能。所以 SQLAlchemy 的开发者就再开发了 Alembic 这一款 Database Migration（数据迁移跟踪记录）软件来弥补这一缺失。
参见《用 Flask 来写个轻博客 (8) — (M)VC_Alembic 管理数据库结构的升级和降级》一文。
gormigrate
在 Golang 生态中，GORM 同样是一款优秀的 ORM 框架，并且自身提供了一定程度的迁移功能，包括：AutoMigrate 和 Mirgator DDL 操作方法两个层面。gormigrate 就是基于以上两种能力进行封装的版本控制工具，也称为：GORM 迁移助手。
参见《Go 语言编程 — gormigrate GORM 的数据库迁移助手》一文。
本文地址：https://blog.csdn.net/Jmilk/article/details/108967204