SQL数据库建模应以业务需求为先，兼顾一致性、迭代效率与查询性能，通常从3NF出发并依读写特征动态调整；需先梳理业务动线、明确实体关系与状态流转，再设计模型。
SQL数据库建模不是单纯追求高范式，而是让结构既满足数据一致性要求，又支撑业务快速迭代和查询效率。关键在“够用”——第三范式（3NF）通常是起点，但要根据读写特征、变更频率、团队能力动态调整。
先理清业务动线，再画实体关系
别一上来就画ER图。花半天和业务方对齐核心流程：比如电商的“下单→支付→发货→售后”，每个环节涉及哪些主体（用户、订单、商品、库存、物流单）、关键动作（创建、修改、取消）、状态流转（待支付→已支付→已发货）。这些直接决定主实体、关联方式和是否需要冗余字段。
建议：
• 用动词短语标注关系（如“用户提交订单”、“订单包含商品”），避免模糊的“属于”“相关”；
• 把高频查询路径列出来（如“查某用户最近3笔未完成订单及对应商品信息”），后续反向验证关联设计是否支持；
• 对存在明显读写分离的模块（如日志、报表统计），可提前规划为独立子模型，不强求与主业务库统一范式。
范式不是越高越好，降维要有依据
3NF能消除大部分数据冗余和更新异常，但实际中常需适度退化：
• 冗余必要字段：订单表保留用户昵称、收货省市区（而非只存user_id），避免大促时连表查询压垮用户中心；
• 合并稳定维度：商品类目树层级固定且查询极频繁，可将一级类目名称、二级类目ID等直接存入商品表，省去多次JOIN；
• 拆分长生命周期数据：订单主表（订单号、状态、时间）和订单明细表（商品ID、数量、单价）必须分离（符合2NF），但“订单快照”（下单时的商品名称、价格）建议单独存，防止原商品信息被改导致对账不一致。
预留演进空间，别把表结构写死
业务会变，建模要留缝：
• 字段命名不用“type1/type2”，而用“ext_info_json”或“custom_attrs”（JSON/TEXT类型），存非核心扩展属性，后期可平滑转为独立扩展表；
• 主键优先用自增BIGINT或UUID，避免用业务字段（如手机号、身份证号）作主键，一旦规则变化或数据清洗就卡住；
• 对可能分库分表的表（如订单、行为日志），从建表起就加shard_key字段（如user_id），即使当前单库也保持结构兼容；
• 所有时间字段统一用UTC DATETIME，应用层负责时区转换，避免跨地区业务出错。
用小步验证代替一步到位
上线前做三件事：
• 拿真实业务SQL跑一遍执行计划，重点看JOIN数、扫描行数、是否命中索引；
• 模拟高并发写入（如批量插入10万订单），观察锁等待、慢查询日志；
• 让前端或BI同学用新模型写3个典型报表SQL，卡点就是设计盲区。
不复杂但容易忽略。
