Navicat模型转换不支持跨库自动结构映射，仅限同源PDM内部调整；异构迁移需配合PowerDesigner或手动建模，否则导出SQL不可用。
Navicat 的模型转换功能本身不支持跨数据库类型的自动结构映射，它只做同源物理模型（PDM）内部调整；真要用于异构迁移，必须配合 PowerDesigner 或手动建模流程，否则容易导出不可用的 SQL。
Navicat 的「模型」功能根本不是为异构迁移设计的
Navicat Premium 自带的「模型」模块（ER 图、逆向工程）仅支持单库逆向生成 PDM，且导出的 DDL 严格绑定源库语法。比如从 MySQL 逆向出模型再导出 SQL，仍是 ENGINE=InnoDB + AUTO_INCREMENT 的 MySQL 语法，无法直接在 Oracle 或 SQL Server 上执行。
常见误操作：右键表 → 「导出模型」→ 选 Oracle 导出格式 → 结果发现字段类型还是 TINYINT、JSON，主键定义含 PRIMARY KEY AUTO_INCREMENT —— 这些在 Oracle 里全报错。
- Navicat 模型导出时没有类型映射规则配置项，不提供如
JSON → CLOB、ENUM → VARCHAR2(20)这类转换开关 - 它不识别目标库的约束机制差异：比如 PostgreSQL 的
CHECK约束导出到 SQL Server 会丢掉，Oracle 的NOT NULL默认值行为也不兼容 - 逆向生成的模型不包含索引表达式、函数索引、分区定义等高级结构，导出后需人工补全
真正能用的模型迁移路径是 PowerDesigner + Navicat 协作
若团队已有 PowerDesigner（PD），Navicat 只适合做“最后一公里”验证和数据落地，不能当主力建模工具。
标准协作流如下：
- 用 Navicat 从源库（如 MySQL）导出完整
CREATE TABLESQL → 保存为mysql_schema.sql - 在 PowerDesigner 中：File → Reverse Engineer → 选择 MySQL 物理模型 → 导入
mysql_schema.sql→ 得到 PDM - 将该 PDM 转为 CDM（概念模型），清除数据库特有属性（如引擎、自增、注释格式）
- 再把 CDM 转为目标库（如 Oracle）的 PDM → 此时可手动设置类型映射：
INT→NUMBER(10)、DATETIME→TIMESTAMP - 最后从目标 PDM 导出 Oracle 兼容 SQL → 用 Navicat 连接 Oracle 执行该脚本建表
注意：mysql_schema.sql 必须禁用 IF NOT EXISTS 和反引号，否则 PD 逆向失败；Navicat 导出时勾选「兼容 ANSI SQL」可减少语法毛刺。
Navicat 模型能帮上的唯一实操点：结构比对与补漏
当 PowerDesigner 已生成目标库建表语句并执行后，用 Navicat 的「结构同步」功能核验是否遗漏字段或约束。
- 新建两个连接：一个连源 MySQL，一个连目标 Oracle
- 右键源表 → 「结构同步」→ 选择目标连接和对应表 → 点「对比」
- 它会列出所有差异项：比如
id字段在 MySQL 是INT UNSIGNED，Oracle 侧却是NUMBER(10)（没 unsigned 对应）→ 提示你手动加 CHECK 约束 - 但注意：Navicat 不会提示
TEXT→CLOB这类语义等价但类型名不同的“软差异”，得靠人眼识别
这个环节的关键价值不是自动生成，而是暴露那些被建模工具忽略的细节偏差——比如 MySQL 的 TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 在 Oracle 中必须拆成触发器+默认值两部分实现。
团队协作中容易被跳过的致命环节
模型转换只是迁移的起点，真正卡住上线的从来不是建表语句，而是类型语义失真和默认行为偏移。
- MySQL 的
ENUM('a','b')导成 Oracle 的VARCHAR2(1)后，应用层校验逻辑可能失效——因为 Oracle 不阻止插入 'c' - PostgreSQL 的
citext列转成普通TEXT后，大小写敏感查询结果突变，测试环境很难覆盖 - Navicat 导出模型时默认忽略列注释（
COMMENT ON COLUMN），而很多团队靠注释管理字段业务含义，一导就丢
别指望模型工具替你思考业务约束；它只管语法通顺，不管语义安全。每一张表迁移后，必须拿真实业务 SQL 跑一遍，看结果是否一致——这才是模型转换之后最该花时间的地方。
