navicat 的 .ndm 模型文件不能直接进 git，因其为二进制格式，git 无法进行语义级 diff 和自动合并，多人编辑易冲突且人工修复困难，且不包含外键顺序、索引注释等元信息，也无法自动同步至数据库。
navicat 本身不提供数据库模型（er 图）的原生版本管理能力，它只支持对「数据库对象」（如表、视图、存储过程）导出为 sql 文件后交由 git 管理；模型文件（.ndm）是二进制格式，无法 diff、无法合并，也不能被 navicat 自动同步或回滚。
Navicat 的 .ndm 模型文件为什么不能直接进 Git？
.ndm 是 Navicat 自有的二进制模型文件，Git 对它只能做全量比对，看不到字段增删、关系调整等语义变更。多人编辑同一 .ndm 文件后，一旦冲突，Git 无法自动合并，人工修复几乎不可行——你得打开两个版本的 Navicat 分别导出 SQL，再手动比对结构差异。
- Navicat 不生成可读的文本化模型描述（比如类似 DBML 或 YAML 格式）
- 导出的
.sql结构脚本不含外键顺序、索引注释、图表布局等模型元信息 - 修改模型后，Navicat 不会自动更新对应数据库，也不自动导出变更到 Git
替代方案：用 DDL SQL 代替 .ndm 做版本控制
真正能落地的版本管理，是绕过 .ndm，把模型“翻译”成可执行、可比对、可部署的 DDL 脚本：
- 在 Navicat 中设计完模型后，右键模型 → “导出 SQL 文件”，勾选“生成 CREATE TABLE 语句”和“包含外键”
- 确保导出时选择“兼容目标数据库版本”，例如 MySQL 8.0 或 PostgreSQL 15，避免语法不兼容
- 把生成的
schema_name.tables.sql提交到 Git，而非model.ndm - 团队约定：所有结构变更必须先改 SQL，再用 Navicat 的“反向工程”或“执行 SQL”同步到数据库
MySQL / PostgreSQL 场景下容易漏掉的关键项
Navicat 导出 DDL 时默认忽略一些影响一致性的细节，需人工检查或补全：
-
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4这类建表参数不会出现在所有导出模式中，尤其跨版本迁移时易出错 - PostgreSQL 的
OWNER、TABLESPACE、序列绑定（GENERATED BY DEFAULT AS IDENTITY）常被省略 - 索引名若未显式指定，Navicat 可能生成随机名（如
idx_12345），导致两次导出的 SQL 在 Git 中显示大量“无意义变更” - 导出的外键约束不含
ON UPDATE CASCADE等动作，需确认是否需补全
Oracle 用户注意：模型导出更受限
Navicat for Oracle 对模型导出的支持弱于 MySQL 版本：
- 不支持导出物化视图、分区表定义、高级队列配置等企业级特性
- 导出的
CREATE TABLE语句默认不含SEGMENT CREATION IMMEDIATE等存储子句 - 从模型反向生成 DDL 时，中文注释可能乱码，需提前设置客户端字符集为
AL32UTF8 - Oracle 的
DBA_OBJECTS和 Navicat 模型之间没有双向校验机制，改了模型不等于改了库，极易脱节
模型版本管理真正的难点不在工具操作，而在于团队是否接受“模型即代码”的协作纪律：DDL 必须成为唯一信源，.ndm 只作为本地辅助设计工具存在，且每次重大变更后必须重新导出并提交 SQL —— 否则 Git 里存的就只是个无法验证、无法部署的摆设。
