大多数开发团队都会毫不犹豫地对应用程序代码进行版本控制。拉取请求、提交记录和分支策略都是标准做法。然而，支撑应用程序的数据库模式却往往通过手动修改、非正式笔记和团队集体记忆来管理。一旦出现故障，或者有新开发人员加入团队，这种做法往往很快就会崩溃。本指南将解释什么是模式版本控制、它为何重要，以及如何利用 Navicat 生成的 SQL 脚本将其整合到你的工作流中。
什么是模式版本控制？
模式版本控制是指将数据库结构（包括表、索引、视图、存储过程和约束）视为代码，像 Git 这样的版本控制系统会对其进行跟踪，其严格程度与应用程序源文件相同。对模式的每次更改都会被记录为一个独立的、可读的 SQL 文件，并附带一条有意义的提交信息，与代码库中的其他部分一同存储。
其结果是，你将获得一份完整且可审计的数据库演变历史：谁添加了哪一列、外键是在何时引入的、上次部署前的模式是什么样子的。更实际地说，这意味着团队中的任何开发人员都可以检出代码库，并准确了解数据库应处于何种状态。
两种方法：基于状态的方法和基于迁移的方法
模式版本控制主要有两种方法，了解它们之间的区别有助于你为团队选择合适的方法。
基于状态的方法会维护一个（或一组）SQL 文件，用于表示当前完整的模式。当模式发生变化时，该文件会被更新，并提交新版本。这种方法虽然简单易懂，但在将更改应用到现有数据库时，需要将目标状态与当前状态进行比较。
基于迁移的方法将每项更改表示为一个独立的、按顺序编号的迁移脚本：一个用于添加列的脚本、一个用于创建索引的脚本、一个用于重命名表的脚本……每项更改都是一个独立的文件，按顺序应用。这种方法的管理难度较大，但能为你提供每项更改的精确、分步历史记录，并使你能够轻松地从数据库历史中的任意点将其更新到最新状态。
实际上，许多团队采用了一种混合方案：对于增量变更，使用基于迁移的工作流；同时定期提交完整的模式导出作为参考快照。
这对团队为何重要
如果没有模式版本控制，数据库变更就会变成一个协调问题。两名分别负责不同功能的开发人员可能会同时修改同一张表。某项变更被应用到生产环境，却从未被记录下来，导致开发数据库与生产环境逐渐出现不一致。此时需要搭建一个新的环境，但没有人能确切知道当前模式是由哪些变更按什么顺序产生的。
对模式进行版本控制可以解决所有这些问题。更改需经过与代码相同的审查流程，通常包括提交拉取请求、代码审查，最后进行合并。每次修改都会记录在 Git 仓库中，并附有时间戳、作者以及说明更改原因的提交信息。要从头重建任何环境，只需按顺序运行脚本即可。
Navicat 如何支持模式版本控制工作流
Navicat 与 Git 协同工作，提供了一套工具，可让你准确、快速且可靠地生成脚本——而模式版本控制工作流中的大部分障碍正源于此。
最直接的方法是“转储 SQL 文件”。此操作会将数据库对象（包括表、视图、函数、存储过程等）的完整 DDL 导出为纯文本 SQL 文件。该文件可直接作为完整的模式快照放入 Git 仓库中。对于基于状态的方法，这通常就是你所需的一切：进行修改、导出模式、提交更新后的文件！
对于基于迁移的工作流，“结构同步”工具更为实用。它会并排比较两个数据库——例如，将你的开发数据库与预发布数据库进行对比——识别出所有结构差异，并生成一个 SQL 脚本，使目标数据库与源数据库保持一致。你无需手动编写 ALTER TABLE 语句，只需在开发环境中使用 Navicat 的可视化表设计器进行修改，然后通过“结构同步”功能自动生成迁移脚本。该脚本将成为你下一个编号的迁移文件，随时可供审查和提交。
Navicat Data Modeler 为那些在实施前需要通过可视化方式设计模式的团队提供了又一实用工具。物理模型准备就绪后，其“导出模型到 SQL 或脚本文件”功能可为建模后的模式生成完整的创建脚本，并允许用户控制要包含的组件，例如参照完整性规则、注释、字符集等。生成的文件结构清晰、格式统一，可立即提交到代码库或直接在新的数据库中运行。
在所有这些工作流中，其基本原理都是相同的：Navicat 负责将可视化模式设计或实时数据库状态转换为 Git 能够追踪的 SQL 语句。你既能享受图形化工具带来的便利，又不会牺牲版本控制所提供的可审计性和协作性。
结语
开始进行模式版本控制并不需要对团队的工作方式进行根本性改变：只需在代码库中选择一个文件夹，开始提交模式脚本，然后以此为基础逐步推进即可。利用 Navicat 的脚本生成和结构同步工具来一致地生成这些脚本，既能消除导致该实践难以持续的手动操作，又能确保数据库的历史记录与代码库的其他部分一样清晰易读。
