4、Schema设计原则：从业务出发，以终为始

做Schema设计这么多年，我最大的感触就是：别一开始就想着怎么建表、怎么定字段类型。很多团队上来就讨论「这个字段用int还是varchar」，结果业务一跑就发现表结构根本撑不住。

为什么会这样？因为脱离了业务场景。

我个人习惯，拿到一个Schema设计任务，先问三个问题：

• 这个数据最终要给谁用？
• 用的时候要查什么？
• 数据从哪来、怎么变？

说白了，就是以终为始。先想清楚终点，再倒推设计。

4.1 业务驱动：先画业务流程图，再画ER图

我在项目中遇到过最典型的反面教材：一个电商系统，技术团队花了两周设计出完美的第三范式Schema，结果上线第一天就发现——订单查询要join 7张表，每次请求耗时3秒以上。

问题出在哪？他们只考虑了「数据怎么存」，没考虑「数据怎么取」。

我建议的做法是：

1. 先画业务流程图——理清核心业务流程，比如「用户下单→支付→发货→收货」
2. 标注关键查询点——每个环节需要查什么数据？查几次？
3. 再画ER图——根据查询路径反推表结构和关联关系

举个例子，一个订单系统，业务上最频繁的查询是「查看我的订单列表」。那这个查询需要哪些字段？订单号、商品名称、金额、状态、时间。这些字段就应该尽量放在一张表里，或者最多join 1-2张表。

4.2 以终为始：从数据消费端倒推设计

你想想看，数据最终流向哪里？

• 给前端页面展示？——那就要考虑字段的展示格式、是否需要冗余存储
• 给数据分析团队跑报表？——那就要考虑维度建模、时间分区
• 给下游系统做API调用？——那就要考虑接口契约、字段命名一致性

我记得有一次做用户画像系统，一开始按传统方式设计了用户表、行为表、标签表。结果数据分析师跑一个「近30天活跃用户画像」的查询，要join 5张表、扫描上亿行数据，跑一次要20分钟。

后来怎么解决的？我们建了一张用户画像宽表，把常用的标签、行为汇总、属性字段全部冗余进去。查询从20分钟降到了2秒。

这就是「以终为始」——既然最终是要做画像分析，那就按分析场景来设计存储结构。

设计方式	存储成本	查询性能	维护复杂度	适用场景
纯范式设计	低	低（多表join）	低	OLTP、高频写入
宽表冗余设计	高	高（单表查询）	中	OLAP、高频读取
混合设计	中	中	高	读写均衡场景

4.3 字段设计的「三问法」

每定义一个字段，我都习惯问自己三个问题：

1. 这个字段真的需要吗？——不要为了「以后可能用到」而加字段，那是技术债务
2. 这个字段的取值空间是什么？——枚举值、范围值、还是自由文本？这决定了字段类型和约束
3. 这个字段会怎么变化？——业务规则变了，字段定义要不要改？

我曾经踩过一个坑：设计订单状态字段时，用了tinyint，0代表待支付，1代表已支付，2代表已发货。结果半年后业务加了「部分退款」「待审核」「已取消」等5个新状态，tinyint不够用了，只能改表结构，影响了一大堆下游系统。

4.4 命名规范：一致性比「优雅」更重要

嗯，这里要注意。很多团队在命名上花太多时间纠结「用user_name还是username」，其实只要全团队统一，哪种都行。

我推荐一套经过多个项目验证的命名规则：

• 表名：业务域_实体名，全小写+下划线，如 order_info、user_account
• 字段名：实体属性，全小写+下划线，如 user_id、create_time
• 主键：统一用 id，自增或雪花ID
• 外键：关联表名_id，如 order_id、user_id
• 时间字段：统一后缀 _time，如 create_time、update_time

说白了，命名规范不是为了好看，是为了降低认知成本。新同学看到 user_id 就知道是用户ID，看到 create_time 就知道是创建时间，不需要猜。

4.5 知识体系总览

下面这张图，是我对本章核心逻辑的总结。你可以把它当作Schema设计的「检查清单」：

4.6 设计评审清单

最后，分享一份我团队内部用的Schema设计评审清单。每次设计完，逐条检查：

检查项	说明	通过标准
业务覆盖度	是否覆盖了所有核心业务流程	每个流程至少对应1张表
查询路径	Top5高频查询是否能在2次join内完成	是
字段必要性	每个字段都有明确的业务含义	无冗余/无用字段
类型合理性	字段类型是否匹配业务取值空间	预留扩展空间
命名一致性	表名、字段名是否符合团队规范	100%一致
索引策略	高频查询条件是否已建索引	覆盖索引优先