物理模型转换前必须确认三件事：目标DBMS版本及限制、逻辑模型是否通过3NF验证、哪些逻辑关系需落地为物理约束；高级扩展类型映射需兼顾兼容性与性能；工具链设置、逆规范化策略须精准匹配业务确定性需求。
物理模型转换前必须确认的三件事
逻辑模型转物理模型不是“点一下就生成sql”的自动化流程，而是设计决策落地的关键环节。没做这三件事就动手，后面八成要返工：
- 确认目标DBMS版本和限制——
Oracle 12c不支持JSON列原生类型，但PostgreSQL 12+支持jsonb索引；MySQL 5.7的GENERATED COLUMN不能作为外键，而8.0.30+已修复 - 检查逻辑模型是否已通过3NF验证——如果还有
address_city和address_province共存于用户表且未拆出cities维度表，物理化后会放大更新异常，尤其在高并发写入时 - 明确哪些“逻辑关系”实际要落地为物理约束——比如ER图里画了
Employee→Department的1:N，但业务允许员工暂无部门（可选参与），那department_id字段就不能设NOT NULL，否则插入失败
高级扩展类型怎么映射才不翻车
所谓“高级扩展类型”，比如JSON、ARRAY、HSTORE、XML、GEOMETRY，它们在逻辑模型里常被简化为“属性”，但物理层一落地就暴露兼容性雷区：
-
JSON字段别盲目用——PostgreSQL的jsonb支持Gin索引和路径查询，但MySQL的JSON类型在GROUP BY或JOIN中性能陡降；若只是存配置项且不查内部字段，用TEXT+ 应用层校验更稳 -
ARRAY慎用于跨库同步场景——PostgreSQL原生支持INTEGER[]，但Debezium捕获变更时默认不解析数组元素变化，Flink CDC也需额外配置array.encoding参数才能正确反序列化 -
GEOMETRY类型依赖空间扩展——PostGIS是插件，不是PostgreSQL内置功能；MySQL 8.0虽有POINT类型，但ST_Distance_Sphere函数只在5.7.6+后可用，旧版本得靠haversine手动算
工具链里最容易被忽略的映射开关
用PowerDesigner、ER/Studio或MySQL Workbench做转换时，图形界面上几个小复选框，直接决定生成SQL是否能跑通：
-
Use ANSI SQL-92 data types关掉——否则NUMERIC(10,2)可能被强制转成DECIMAL，而某些老BI工具对DECIMAL精度推断异常 -
Generate comments as extended properties打开——逻辑模型里的“该字段表示最后一次人工审核时间”这类说明，只有启用此选项才会变成COMMENT ON COLUMN users.audit_time IS '最后一次人工审核时间' -
Convert domains to native types必须开——逻辑模型中定义的PhoneNoDomain若不展开为VARCHAR(20)，生成的PDM里会留空类型，导出SQL时报Unknown data type "PhoneNoDomain"
逆规范化不是“加冗余”，而是加确定性
逻辑模型强调范式，物理模型常要逆规范，但很多人把“加冗余字段”等同于“提升性能”，结果反而拖慢写入、引发数据不一致：
- 冗余字段必须满足“可推导+低更新频次”——比如在
orders表里加customer_name可以，因为客户名极少改；但加customer_balance不行，余额每笔支付都在变，必须实时JOIN或走物化视图 - 优先用
GENERATED COLUMN替代手工维护——full_name VARCHAR(100) GENERATED ALWAYS AS (first_name || ' ' || last_name)比应用层拼接更可靠，且PostgreSQL支持对其建索引 - 避免“伪逆规范”：把
status_code和status_desc同时存在一张表里，却不加CHECK约束或FOREIGN KEY引用状态字典表，等于埋下脏数据定时炸弹
真正难的从来不是“怎么转”，而是“转完之后，当业务提一个新需求，你能不能在5分钟内说清这个字段该加在哪张表、要不要索引、会不会影响同步链路”。模型转换只是起点，后续每次字段变更，都是对当初物理设计边界的再检验。
