数据库表设计需平衡一致性、查询效率与维护成本，以 3NF 为基座，在查多写少、稳定不变、逻辑简单的场景下局部反范式化，并重视索引、分区、UTC 时间等物理设计与演进意识。
数据库表结构设计不是单纯追求理论完美，而是平衡一致性、查询效率和维护成本。范式化能减少冗余、保障数据完整性，反范式化则常用于提升读性能——关键不在“该不该范式”，而在“在什么场景下做何种取舍”。
范式化：从 1NF 到 3NF 的实用落地
实际建表中，真正需要严格遵守的是 1NF（字段原子性）、2NF（消除非主属性对部分主键的依赖）和 3NF（消除传递依赖）。BCNF 和更高范式多见于理论或特殊强一致性系统，业务系统中过度追求反而增加 JOIN 复杂度。
- 1NF 要检查字段是否可拆分：比如“用户标签”存成逗号分隔字符串（”vip,active,ios“）就违反 1NF；应拆为关联表
user_tags(user_id, tag_name)。 - 2NF 常见陷阱是复合主键滥用 ：订单明细表若用
(order_id, product_id)作主键，但product_name只依赖product_id，就存在部分依赖；应将产品信息抽离至products表，明细表仅保留product_id外键。 - 3NF 重点防“间接依赖”：例如用户表里存了
city_name和province_name，而城市归属省份是确定关系，province_name实际依赖city_name而非user_id；应建立cities和provinces字典表，用户表只存city_id。
反范式化：有策略地引入冗余
反范式不是随意加字段，而是针对高频、低更新、强聚合需求的场景，用可控冗余换性能。前提是明确冗余字段的更新机制，避免数据不一致。
- 统计类冗余最安全 ：如商品表增加
sales_count字段，每次下单后通过事务内 UPDATE+ 1 更新；比实时 COUNT(*)快得多，且更新路径唯一、不易出错。 - 常用关联字段可缓存 ：订单表可冗余
user_nickname和product_title，前提是这些字段极少修改（昵称改名频率低、商品标题基本不变），且业务允许几秒级延迟（可通过 MQ 异步刷新）。 - 避免跨多层的冗余：不要在订单表里存“用户所在省份名称”——它需经用户→城市→省份三级推导，一旦中间层变更极易脱节；这类应保持范式，靠视图或应用层组装。
混合设计：范式为基，反范式点刹
成熟系统往往以 3NF 为底座，在少数关键路径上局部反范式。设计时建议按“查多写少、稳定不变、逻辑简单”三原则筛选反范式点。
- 先按 3NF 建出干净的核心模型（用户、订单、商品、地址等主表 + 关联表）；
- 结合慢查询日志和业务 QPS，找出 TOP5 耗时 SQL，分析其瓶颈是否来自多表 JOIN 或 COUNT/SUM 聚合；
- 对确认瓶颈的字段，评估更新频次与一致性要求：若每日更新<10 次且允许最终一致，可加冗余字段 + 异步同步；若实时强一致，则优先优化索引或考虑物化视图（如 PostgreSQL 的 MATERIALIZED VIEW）。
别忽略物理设计与演进意识
再好的逻辑设计，若缺少索引、分区或字符集支持，也会失效。同时，表结构不是上线即定稿——应预留扩展性，比如用jsonb（PostgreSQL）或JSON（MySQL 5.7+）存储非结构化、低查询频率的扩展属性，比不停加字段更可持续。
- 外键要不要加？开发环境 建议开启，帮助发现逻辑错误；生产高并发写入场景可权衡关闭，由应用层或定时校验保障一致性。
- 时间字段统一用 UTC，避免时区转换混乱；所有表标配
created_at、updated_at，必要时加deleted_at支持软删除。 - 小改动优于大重构：当发现某张表因反范式导致更新异常，优先补同步任务或触发器，而不是立刻推翻重设计——稳定压倒完美。
