设计表结构

1. 明确业务场景与需求

1.1 梳理业务流程

例如电商系统中，订单、用户、商品是核心业务实体，需明确它们的关联关系（如用户下单、订单包含商品）。

1.2 确定数据类型与属性

列出每个业务实体的关键属性，如用户表需包含 ID、姓名、手机号、注册时间等。

2. 遵循数据库设计范式

2.1 第一范式（1NF）属性原子性

字段不可再分，例如 “地址” 应拆分为省、市、区、详细地址，而非存储为一个完整字符串。

2.2 第二范式（2NF）消除部分依赖

复合主键表中，非主键字段需完全依赖主键，而非部分依赖。例如订单明细表（订单ID + 商品ID）中，商品价格应依赖商品ID，而非仅订单ID。

2.3 第三范式（3NF）消除传递依赖

字段不依赖于非主键的其他字段，例如用户表中“部门名称” 应通过部门ID关联部门表，而非直接存储（避免部门名称变更时需批量修改用户表）。

3. 设计表结构的核心要素

3.1 表名与字段命名

表名：用业务语义清晰的英文/中文（建议英文，如user_info），避免缩写歧义。
字段名：遵循 “表名_属性” 格式（如user_id），类型与业务含义一致（如create_time用时间戳或 datetime 类型）。

3.2 主键设计

自增主键（INT/BIGINT）：简单高效，适合单表场景（如id AUTO_INCREMENT）。
分布式主键（UUID/雪花算法）：跨库场景下保证唯一性（如电商订单ID）。

3.3 字段类型选择

避免过度使用TEXT等大字段，常用类型：
字符串：VARCHAR（短文本，如用户名）、TEXT（长文本，如商品描述）。
数值：INT（整数）、DECIMAL（精确小数，如金额）。
时间：DATETIME（存储具体时间）、TIMESTAMP（自动更新当前时间）。

3.4 索引设计

在查询频繁的字段创建索引（如user_phone），但避免过度索引（影响写入性能）。

4. 表关系设计

4.1 确定关联关系

一对一（1:1）：如用户表与用户详情表（可合并为一张表，除非详情字段极少使用）。
一对多（1:N）：如部门表（主）与用户表（从），通过外键dept_id关联。
多对多（M:N）：如用户与角色表，需创建中间表（user_role）存储user_id和role_id。

4.2 外键约束

数据库层面通过外键（FOREIGN KEY）保证数据一致性（如删除部门时级联删除该部门用户），但需注意性能开销，可根据场景选择是否启用。

5. 考虑扩展性与性能

5.1 预留扩展字段

设计ext_info字段（JSON 类型）存储未来可能新增的非核心属性（如用户标签），避免频繁修改表结构。

5.2 分表策略

单表数据量过大时（如超千万行），按时间（如订单表按年月分表）或业务维度（如用户表按 ID 哈希分表）拆分。

5.3 冗余设计

为提升查询效率，允许适度数据冗余（如订单表存储用户姓名，避免每次查询都关联用户表），但需确保冗余数据一致性（如用户改名时同步更新订单表）。