Navicat模型工具高级应用：怎样逻辑模型转为物理模型

逻辑模型转物理模型本质是将业务规则翻译为数据库方言，需人工处理字段类型、主外键落地及目标库语法差异，Navicat转换强制面对三大现实问题并依赖四项关键配置检查。

逻辑模型转物理模型，本质是“翻译业务规则为数据库方言”

这一步不是点一下就完事的自动映射，而是把抽象的实体关系（比如“用户-订单是1对多”）翻译成具体数据库能执行的结构定义（比如 user_id int primary key、orders.user_id int not null references users(id)）。navicat 的转换过程会强制你面对三个现实问题：字段类型怎么选、主外键怎么落地、目标数据库到底支持什么语法。

转换前必须检查的 4 个关键配置项

很多人跳过这步直接点“转换”，结果生成的 SQL 在 MySQL 里跑不通，或在达梦里报错。真正起作用的是这四个地方：

在“变换为物理数据模型”向导的“数据类型映射”页，确认 String 映射到了 VARCHAR(255) 而不是 TEXT（后者可能不支持索引）
在“选项”页填的 模式名（如 HR_schema）会变成 SQL 里的 CREATE SCHEMA 或 USE 语句，达梦和 PostgreSQL 对 schema 处理差异很大
逻辑模型中未标注“主键”的实体，在物理模型里不会自动生成 PRIMARY KEY 约束——Navicat 不会替你做这个判断
多对多关系在逻辑层只画连线，但转换后是否生成关联表（如 post_tag），取决于你在关系属性里是否勾选了 创建关联表

生成 SQL 前，务必打开“属性”视图调出字段细节

转换后的物理模型默认只显示表名和字段名，但字段长度、是否允许 NULL、默认值这些关键信息全藏在“属性”视图里。不手动展开看一遍，很容易导出带 INT 却没 AUTO_INCREMENT 的主键，或者把时间字段生成成 DATETIME 却漏掉 DEFAULT CURRENT_TIMESTAMP。

实操建议：
– 右键点击任意表 → 选择 编辑表 → 切换到 属性 视图
– 检查每个字段的 数据类型、长度/精度、允许为空、默认值
– 特别注意外键字段：它的类型必须和被引用字段**完全一致**（比如都是 BIGINT UNSIGNED），否则同步到 MySQL 8.0+ 会失败