Navicat 17的ER模型设计器不支持可视化建表，仅作为只读设计载体；建表必须显式生成DDL脚本并手动执行，且需人工核对数据库类型、保留字、外键引用一致性，同步到数据库会暴力覆盖并清空数据。
Navicat 17 的 ER 模型设计器不支持直接“可视化建表”
很多人误以为在 模型 编辑器里拖拽画完表和关系，点个按钮就能自动建库建表——实际上，navicat 17 的物理模型（physical model）本身是**只读设计载体**，它不带执行 sql 的能力。你画的每张表、每个字段、每条外键线，只是模型数据，并不会触发任何数据库操作。
真正能“建表”的路径只有一条：生成 DDL 脚本 → 手动执行或导入到查询窗口运行。这个过程必须显式触发，没有一键同步或自动部署机制。
- 模型编辑器中右键任意表 →
复制为 SQL只复制单表语句，不含外键、索引等依赖对象 - 完整建库脚本必须走：
文件 → 生成 SQL 文件→ 勾选“创建数据库”“创建表”“创建外键”等选项 - 生成的 SQL 默认不含
IF NOT EXISTS，直接执行可能报错（如表已存在），需手动加判断或清空目标库 - 若目标数据库不支持某语法（如 MySQL 的
ENGINE=InnoDB在 PostgreSQL 中非法），脚本会生成但执行失败——Navicat 不做跨库语法适配校验
导出模型到物理数据库前必须确认三件事
跳过检查直接点 生成 SQL 文件 或 同步到数据库，大概率导致建表失败或结构错乱。以下三项必须人工核对：
-
模型属性中设置的数据库类型与目标连接完全一致（例如模型设为MySQL 8.0，但连接的是MySQL 5.7，生成的JSON字段语法会报错） - 所有表名、字段名未使用数据库保留字（如
order、group），否则导出的 SQL 缺少反引号包裹，执行时直接报错 - 外键引用的父表必须已在模型中存在且命名拼写完全一致（大小写敏感！比如模型里写了
user，但实际库中是User，生成的外键语句会指向不存在的表）
“同步到数据库”功能在 Navicat 17 里实际是单向覆盖
模型 → 同步到数据库 看似智能，实则是暴力替换逻辑：它会先 DROP 所有目标表，再 CREATE 新表。这不是增量更新，也不比对差异。
- 如果目标库已有业务数据，同步操作会直接清空全部表内容（即使模型里没改字段）
- 同步过程不提示“是否保留数据”，也不提供生成对比报告的选项；一旦点击【开始】，不可中断、不可撤回
- 若模型中某张表设置了主键，但目标库该表原本是无主键的，同步后主键被加上，但原有数据不会自动去重——可能引发后续插入重复键错误
- 同步日志仅显示“成功/失败”，不输出具体执行的 SQL，排查问题时得回头手动跑一遍
生成 SQL 文件再比对
导出 PDF 或 PNG 不能代替建表验证
有人习惯先导出 ER 图为 PDF 来“确认结构”，再导出 SQL——这容易掩盖关键问题。PDF 渲染正常 ≠ 模型语义合法。
- 模型允许你画出循环外键（A→B→C→A），PDF 能正常显示，但生成的 SQL 在大多数数据库里无法执行
- 字段类型写成
varchar(255)能渲染，但如果目标库是 SQLite，它会忽略长度限制；而写成string这种非标类型，PDF 正常显示，但生成 SQL 时会被静默转成VARCHAR(45)（Navicat 17 的默认 fallback） - 中文字段注释在 PDF 里显示正常，但导出的 SQL 可能缺失
COMMENT子句（尤其当模型字体设为 SimSun 但导出时未勾选“包含注释”）
真正可靠的验证方式，永远是：生成 SQL → 复制到查询窗口 → 手动执行 → 看错误提示。其他任何可视化动作都只是辅助，不是确认。
