# 数据模型：设计的"骨架"
::: tip 🎯 核心问题
**如何设计合理的数据结构？** 这就像问：盖房子前怎么画图纸？仓库怎么摆放货物最高效？家族谱系怎么记录最清晰？数据模型解决的就是"数据如何组织"的问题。
:::
---
## 0. 先问一个问题：你有没有经历过这些噩梦？
**场景一：表设计混乱**
```
users 表：
| id | name | address | order_1 | order_1_amount | order_2 | order_2_amount | ... |
```
订单字段重复 100 次，每次下单都要改表结构。
**场景二：数据冗余严重**
```
orders 表：
| id | user_name | user_email | user_phone | product_name | product_price |
```
用户信息、商品信息全部复制到订单表，修改用户邮箱需要更新所有历史订单。
**场景三：关系处理错误**
```
posts 表：
| id | title | tags |
| 1 | Vue入门 | vue,frontend,javascript |
```
用逗号分隔存储标签，无法查询"有哪些文章包含 vue 标签"。
---
**好的数据模型就像建筑蓝图**——结构清晰、扩展灵活、关系明确。
---
## 0.5 从零开始：什么是数据？
在深入了解数据模型之前，我们需要先搞清楚几个最基础的问题。
### 0.5.1 什么是数据？
**数据**就是对事物的记录。
**生活中的例子**：
- 你的购物车里的商品：商品名称、价格、数量、图片链接
- 你的通讯录：姓名、电话、邮箱、地址
- 你的书架：书名、作者、出版社、出版年份
- 你的游戏存档：等级、经验值、装备、金币
这些都是"数据"——它们记录了某种信息。
### 0.5.2 数据为什么要组织？
想象一下这些场景：
**场景一：杂乱的通讯录**
```
张三 13800138000 北京朝阳区
李四 13900139000 上海浦东新区
王五 13700137000 lisi@example.com
赵六 13600136000 广州天河区 zhaoliu@example.com
```
所有信息混在一起，你想：
- 找"李四"的电话号码 → 需要逐行扫描
- 找所有"广州"的人 → 需要逐行判断
- 添加一个人的邮箱 → 格式不统一，不知道放哪里
**场景二：有组织的通讯录**
```
姓名 电话 邮箱 城市
张三 13800138000 zhangsan@example.com 北京朝阳区
李四 13900139000 lisi@example.com 上海浦东新区
王五 13700137000 wangwu@example.com 深圳南山区
赵六 13600136000 zhaoliu@example.com 广州天河区
```
现在：
- 找"李四"的电话 → 在"姓名"列查找 → 快速定位
- 找所有"广州"的人 → 在"城市"列筛选 → 一目了然
- 添加新信息 → 按列填写 → 格式统一
**结论**：**数据需要组织才能高效使用！**
### 0.5.3 一个简单的例子：记录你的书架
让我们用一个最简单的例子——"记录你的书架"——来理解数据模型是如何一步步形成的。
**第一步：原始想法（用一张纸记录）**
```
我的书架：
《JavaScript高级程序设计》 Matt Frisbie 2020年 人民邮电出版社
《Vue.js设计与实现》 霍春阳 2022年 人民邮电出版社
《深入浅出Node.js》 朴灵 2013年 人民邮电出版社
```
**问题**：
- 想找"2022年"出版的书 → 需要逐行看
- 想找"人民邮电出版社"的所有书 → 需要逐行判断
- 想按"出版年份"排序 → 需要重新整理
**第二步：用表格组织（这就是数据模型的雏形）**
```
| 书名 | 作者 | 出版年份 | 出版社 |
|---------------------------|-----------|---------|--------------|
| JavaScript高级程序设计 | Matt Frisbie | 2020 | 人民邮电出版社 |
| Vue.js设计与实现 | 霍春阳 | 2022 | 人民邮电出版社 |
| 深入浅出Node.js | 朴灵 | 2013 | 人民邮电出版社 |
```
**改进**：
- 每列有明确的含义（书名、作者、出版年份、出版社）
- 可以按任意列排序
- 可以按任意列筛选（比如找出所有"人民邮电出版社"的书）
**第三步：发现新需求（多本书有多个作者）**
```
问题：《重构：改善既有代码的设计》有两个作者：Martin Fowler 和 Kent Beck
```
怎么记录？
**错误做法**：把两个名字塞进一个字段
```
| 书名 | 作者 |
|------|------------------------|
| 重构 | Martin Fowler, Kent Beck |
```
**问题**：
- 无法单独查询"Martin Fowler 写了哪些书"
- 无法统计"每个作者写了几本书"
- 修改作者名字时需要字符串操作
**正确做法**：拆分成两张表，用"关系"连接
```
书籍表：
| 书名 | 出版年份 |
|--------------|---------|
| 重构 | 2019 |
| JavaScript高级程序设计 | 2020 |
作者表：
| 作者姓名 |
|------------------|
| Martin Fowler |
| Kent Beck |
| Matt Frisbie |
书籍-作者关联表：
| 书名 | 作者姓名 |
|--------------|---------------|
| 重构 | Martin Fowler |
| 重构 | Kent Beck |
| JavaScript高级程序设计 | Matt Frisbie |
```
**这就是数据模型设计的核心**：
1. **识别实体**（书、作者）
2. **设计属性**（书名、出版年份、作者姓名）
3. **建立关系**（一本书可以有多个作者）
### 0.5.4 什么是数据模型？
**数据模型**（Data Model）就是对"数据如何组织、存储、关联"的设计方案。
**用盖房子来类比**：
| 盖房子 | 数据模型 |
|:-----|:-------|
| 蓝图设计 | 数据模型设计 |
| 客厅、卧室、厨房 | 不同的表（用户表、订单表、商品表） |
| 承重墙、水电管线 | 主键、外键（关系） |
| 房屋的格局 | 表的结构（字段、类型） |
::: tip 💡 为什么要设计数据模型？
想象一下：
- 没有蓝图盖房子 → 房子可能会倒、功能混乱、无法扩建
- 没有数据模型写程序 → 数据冗余、查询缓慢、难以维护
**好的数据模型让你：**
- 数据不重复（节省空间）
- 查询快速（性能好）
- 易于扩展（新增功能方便）
- 避免错误（数据一致性强）
:::
---
## 1. 数据模型的重要性
**数据模型**（Data Model）是对现实世界的抽象，描述数据如何存储、组织和关联。
### 1.1 用建筑来类比
| 建筑概念 | 对应概念 | 说明 |
| :--- | :--- | :--- |
| 蓝图 | 数据模型 | 设计的"骨架"和结构 |
| 承重墙 | 主键/外键 | 保证结构稳固的核心 |
| 房间布局 | 表结构 | 各个功能单元的设计 |
| 水电管线 | 关系 | 连接各个部分的数据流 |
### 1.2 数据模型的层次
| 层次 | 内容 | 示例 |
| :--- | :--- | :--- |
| **概念模型** | 业务对象和关系 | 用户、订单、商品 |
| **逻辑模型** | 表结构、关系类型 | users 表 1:N orders 表 |
| **物理模型** | 具体存储实现 | 字段类型、索引、分区 |
---
## 2. ER 图：实体关系建模
### 2.0 为什么需要画图？
想象你和朋友聊天，描述你的家庭关系：
**用文字描述**：
> "我有一个爸爸、一个妈妈、一个哥哥。我爸爸的父母是我爷爷奶奶，我妈妈的父母是我外公外婆。我哥哥结婚了，有一个嫂子。"
听的人可能会困惑：
- 你哥哥和你嫂子是什么关系？
- 你和你嫂子是什么关系？
- 如果你哥哥又有孩子，那孩子和你是什么关系？
**用图画出来**：
```
爷爷 -- 奶奶
|
爸爸 -- 妈妈 -- 外公 -- 外婆
| |
你 哥哥 -- 嫂子
```
瞬间就清晰了！
**ER 图的作用**：
- 把复杂的"数据关系"可视化
- 帮助设计者理清思路
- 方便团队沟通讨论
- 在写代码前发现问题
**ER 图**（Entity-Relationship Diagram，实体关系图）就是专门用来画"数据关系"的工具。
### 2.1 手把手：从零画出你的第一个 ER 图
让我们用一个**家庭关系**的例子，一步步画出 ER 图。
#### 第一步：识别"实体"
**实体**（Entity）就是现实世界中的"对象"或"事物"。
在家庭关系中，实体有：
- 人（Person）
- 家庭（Family）
**问题**：我们把"人"作为核心实体，"家庭"可以暂时忽略。
#### 第二步：确定"属性"
**属性**（Attribute）就是实体的"特征"或"信息"。
"人"这个实体的属性：
- 姓名（name）
- 性别（gender）
- 出生日期（birth_date）
- 身份证号（id_card）
#### 第三步：识别"关系"
**关系**（Relationship）就是实体之间的"联系"。
家庭中的关系：
- 结婚（丈夫 ↔ 妻子）
- 亲子（父母 → 孩子）
- 兄弟姐妹（兄弟姐妹之间）
#### 第四步：确定"关系类型"
每种关系都有一个"基数"（Cardinality）：
**一对一（1:1）**：
- 一个丈夫 ↔ 一个妻子（假设一夫一妻制）
```
丈夫 1 ---- 1 妻子
```
**一对多（1:N）**：
- 一个父母 → 多个孩子
```
父母 1 ---- N 孩子
```
**多对多（M:N）**：
- 多个兄弟姐妹 ↔ 多个兄弟姐妹
```
兄弟姐妹 M ---- N 兄弟姐妹
```
#### 第五步：画出完整的 ER 图
**ER 图的基本符号**：
| 符号 | 名称 | 含义 | 生活类比 |
|:---:|:---:|:---|:---|
| ▭ | 矩形 | 实体（表） | 一个"箱子"装一类数据 |
| ▭ | 椭圆 | 属性（字段） | 箱子里的"物品" |
| ◇ | 菱形 | 关系 | 箱子之间的"连线" |
| — | 线条 | 连接 | 把东西串起来的"绳子" |
**家庭关系的 ER 图示例**：
```
┌─────────┐
│ 人 │
└─────────┘
│ 姓名 │
│ 性别 │
│ 出生日期│
└─────────┘
│
│
┌────┴────┐
│ │
结婚 亲子
1:1 1:N
```
::: tip 💡 为什么要画 ER 图？
1. **设计前理清思路**：画图比改代码容易得多
2. **团队沟通**：一张图胜过千言万语
3. **发现遗漏**：画图时容易发现"咦，这个关系好像没考虑"
4. **文档留存**：新人看图就能理解系统结构
:::
### 2.2 核心概念详解
#### 实体（Entity）
**实体**就是你想记录的"对象"或"事物"。
**示例**：
- 用户（User）
- 订单（Order）
- 商品（Product）
- 文章（Article）
**如何识别实体？**
问自己："我需要记录什么信息？"
- 我需要记录用户 → 用户实体
- 我需要记录订单 → 订单实体
- 我需要记录商品 → 商品实体
#### 属性（Attribute）
**属性**就是实体的"特征"或"详细信息"。
**示例**：
- 用户实体的属性：用户名、邮箱、电话、注册时间
- 订单实体的属性：订单号、金额、状态、创建时间
**如何识别属性？**
问自己："这个实体有哪些信息需要记录？"
#### 关系（Relationship）
**关系**就是实体之间的"联系"。
**示例**：
- 用户**下**订单（下单关系）
- 订单**包含**商品（包含关系）
- 用户**购买**商品（购买关系）
**如何识别关系？**
问自己："这些实体之间有什么关联？"
### 2.3 用一个简单例子练习
让我们画一个**班级管理系统**的 ER 图。
#### 第一步：识别实体
在这个系统中，有哪些实体？
- 学生（Student）
- 课程（Course）
- 老师（Teacher）
#### 第二步：确定属性
每个实体有哪些属性？
**学生**：学号、姓名、班级
**课程**：课程编号、课程名称、学分
**老师**：工号、姓名、职称
#### 第三步：识别关系
- 学生**选修**课程（多对多：一个学生可以选多门课，一门课可以被多个学生选）
- 老师**教授**课程（一对多：一个老师可以教多门课，一门课通常由一个老师教）
#### 第四步：画出 ER 图
```
┌─────────┐
│ 学生 │
└─────────┘
│ 学号 │
│ 姓名 │
│ 班级 │
└─────────┘
│
│ 选修 (M:N)
│
┌─────────┐
│ 课程 │
└─────────┘
│ 课程编号│
│ 课程名称│
│ 学分 │
└─────────┘
│
│ 教授 (1:N)
│
┌─────────┐
│ 老师 │
└─────────┘
│ 工号 │
│ 姓名 │
│ 职称 │
└─────────┘
```
### 2.4 核心概念总结表
| 符号 | 含义 | 示例 | 通俗理解 |
| :--- | :--- | :--- | :--- |
| **矩形** | 实体（表） | 用户、订单、商品 | 一个"箱子"装一类数据 |
| **椭圆** | 属性（字段） | 用户名、邮箱、电话 | 箱子里的"物品" |
| **菱形** | 关系 | 下单、支付、评论 | 箱子之间的"连线" |
| **线条** | 连接 | 表与表的关联 | 把东西串起来的"绳子" |
| 符号 | 含义 | 示例 |
| :--- | :--- | :--- |
| **矩形** | 实体（表） | 用户、订单、商品 |
| **椭圆** | 属性（字段） | 用户名、邮箱、电话 |
| **菱形** | 关系 | 下单、支付、评论 |
| **线条** | 连接 | 表与表的关联 |
### 2.5 完整的 ER 图示例
👇 **动手试试看**：探索用户-订单-商品的实体关系模型：
---
## 3. 关系类型：一对一、一对多、多对多
关系类型决定了表之间如何关联，是数据模型设计的核心。
### 3.1 一对一（One-to-One）
#### 3.1.1 什么是"一对一"？
**定义**：A 表的一条记录对应 B 表的一条记录，反过来也成立。
**生活类比**：
- 一个人 ↔ 一个身份证号码
- 一个丈夫 ↔ 一个妻子（一夫一妻制）
- 一个国家 ↔ 一个首都
#### 3.1.2 用生活场景理解
想象你在做一个**用户系统**：
**场景**：用户基本信息 + 详细资料
你发现用户信息太多了：
- 基本信息：用户名、邮箱、密码（经常用）
- 详细资料：昵称、头像、个人简介、生日、地址、手机号（不常用）
**问题**：要不要把所有信息放一张表？
**方案一：全放一张表**
```
users 表：
| id | username | email | password | nickname | avatar | bio | birthday | address | phone |
```
**缺点**：
- 表太宽，字段太多（超过 20 个）
- 查询"登录"时只需要基本字段，但会加载所有字段（浪费性能）
- 详细资料可能很长（bio、avatar），拖慢查询速度
**方案二：拆分成两张表（一对一关系）**
```
users 表（基本信息）：
| id | username | email | password_hash |
| 1 | zhangsan | zhangsan@qq.com | xxxxx... |
user_profiles 表（详细资料）：
| user_id | nickname | avatar | bio | birthday |
| 1 | 小张 | ... | 热爱编程... | 1995-06-15 |
```
**优点**：
- 登录时只查 users 表，快速
- 查看资料时再 JOIN user_profiles 表
- 分离敏感信息（password）和非敏感信息
**关系表示**：
```
users (1) ---- (1) user_profiles
| |
id (主键) user_id (主键 + 外键)
```
#### 3.1.3 SQL 实现
**方式 1：外键唯一约束（推荐）**
```sql
-- 用户表
CREATE TABLE users (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
username VARCHAR(50) NOT NULL,
email VARCHAR(100) UNIQUE NOT NULL,
password_hash VARCHAR(255) NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- 用户详细资料表
CREATE TABLE user_profiles (
user_id BIGINT PRIMARY KEY, -- user_id 同时是主键和外键
nickname VARCHAR(50),
avatar VARCHAR(255),
bio TEXT,
birthday DATE,
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);
-- 插入数据
INSERT INTO users (id, username, email, password_hash) VALUES
(1, 'zhangsan', 'zhangsan@qq.com', 'hashed_password');
INSERT INTO user_profiles (user_id, nickname, bio) VALUES
(1, '小张', '热爱编程，热爱生活');
-- 查询：获取用户完整信息
SELECT u.*, p.nickname, p.bio, p.avatar
FROM users u
LEFT JOIN user_profiles p ON u.id = p.user_id
WHERE u.id = 1;
```
**方式 2：在主表添加外键（不推荐）**
```sql
-- 详细资料表
CREATE TABLE user_profiles (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
nickname VARCHAR(50),
bio TEXT
);
-- 用户表（引用 profile）
CREATE TABLE users (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
username VARCHAR(50),
profile_id BIGINT UNIQUE, -- 唯一约束
FOREIGN KEY (profile_id) REFERENCES user_profiles(id)
);
```
**为什么方式 1 更好？**
- 用户是"主实体"，资料是"从属信息"
- 先有用户，再有资料
- 删除用户时，资料也应该删除（CASCADE）
#### 3.1.4 数据样子
```
users 表：
┌────┬──────────┬─────────────────┬───────────────┐
│ id │ username │ email │ password_hash │
├────┼──────────┼─────────────────┼───────────────┤
│ 1 │ zhangsan │ zhangsan@qq.com │ xxxxx... │
│ 2 │ lisi │ lisi@qq.com │ yyyyy... │
└────┴──────────┴─────────────────┴───────────────┘
│
│ 一对一关系
│
user_profiles 表：
┌──────────┬──────────┬─────────┬──────────────┐
│ user_id │ nickname │ avatar │ bio │
├──────────┼──────────┼─────────┼──────────────┤
│ 1 │ 小张 │ avatar1 │ 热爱编程... │
│ 2 │ 小李 │ avatar2 │ 喜欢读书... │
└──────────┴──────────┴─────────┴──────────────┘
```
#### 3.1.5 什么时候用一对一？
**适合使用的场景**：
- 字段数量过多（超过 20 个字段）
- 需要分离敏感信息（密码、支付信息）
- 部分字段很少查询（登录时不需要加载简介、头像）
- 需要独立扩展（用户资料可能有多种类型：个人、企业）
**不适合使用的场景**：
- 字段不多（少于 15 个），直接放一张表即可
- 所有字段都会频繁查询（拆分反而需要 JOIN，降低性能）
::: tip 💡 一对一关系的判断标准
问自己："A 的一条记录能对应 B 的多条记录吗？"
- 如果能 → 一对多或多对多
- 如果不能 → 可能是一对一
再问："B 的一条记录能对应 A 的多条记录吗？"
- 如果能 → 一对多
- 如果不能 → 一对一
:::
```sql
users 表： user_profiles 表：
| id | username | | user_id | bio | avatar |
| 1 | 张三 | | 1 | ... | ... |
```
**实现方式**：
```sql
-- 方式 1：外键唯一约束
CREATE TABLE user_profiles (
user_id BIGINT PRIMARY KEY,
bio TEXT,
avatar VARCHAR(255),
FOREIGN KEY (user_id) REFERENCES users(id)
);
-- 方式 2：直接在主表扩展
CREATE TABLE users (
id BIGINT PRIMARY KEY,
username VARCHAR(50),
profile_id BIGINT UNIQUE,
FOREIGN KEY (profile_id) REFERENCES user_profiles(id)
);
```
**使用场景**：
- 用户表 + 详细资料表（分离敏感信息）
- 订单表 + 支付信息表（分离支付数据）
- 商品表 + 库存表（分离库存管理）
::: tip 💡 一对一关系的判断标准
问自己："A 的一条记录能对应 B 的多条记录吗？"
- 如果能 → 一对多或多对多
- 如果不能 → 可能是一对一
再问："B 的一条记录能对应 A 的多条记录吗？"
- 如果能 → 一对多
- 如果不能 → 一对一
:::
### 3.2 一对多（One-to-Many）
#### 3.2.1 什么是"一对多"？
**定义**：A 表的一条记录可以对应 B 表的多条记录，但 B 的一条记录只能对应 A 的一条记录。
**生活类比**：
- 一个母亲 → 多个孩子
- 一个班级 → 多个学生
- 一个作者 → 多篇文章
**这是最常见的关系！约占数据库关系的 70%。**
#### 3.2.2 用生活场景理解
想象你在做一个**电商系统**：
**场景**：用户和订单
**需求**：
- 一个用户可以下多个订单
- 一个订单只能属于一个用户
**怎么设计数据库？**
**方案一：全放一张表（错误）**
```
users 表：
| id | username | order_1 | order_1_amount | order_2 | order_2_amount | ... |
| 1 | 张三 | 100 | 500 | 101 | 300 | ... |
```
**问题**：
- 一个用户最多能下多少单？10 个？100 个？
- 字段数量爆炸，表结构混乱
- 无法查询"某个订单属于哪个用户"
**方案二：拆分成两张表（一对多关系）**
```
users 表：
| id | username | email |
| 1 | 张三 | zhangsan@qq.com |
orders 表：
| id | user_id | amount | status |
| 1 | 1 | 500 | paid |
| 2 | 1 | 300 | shipping |
| 3 | 1 | 800 | completed |
```
**关系表示**：
```
users (1) ---- (N) orders
| |
id (主键) user_id (外键)
```
**关键点**：在"多"的那张表（orders）添加"外键"（user_id），指向"一"的那张表（users）。
#### 3.2.3 SQL 实现
```sql
-- 用户表（"一"的那一方）
CREATE TABLE users (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
username VARCHAR(50) NOT NULL,
email VARCHAR(100) UNIQUE NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- 订单表（"多"的那一方）
CREATE TABLE orders (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
user_id BIGINT NOT NULL, -- 外键，指向 users 表
amount DECIMAL(10, 2) NOT NULL, -- 订单金额
status VARCHAR(20) DEFAULT 'pending', -- 订单状态
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);
-- 插入数据
INSERT INTO users (id, username, email) VALUES
(1, '张三', 'zhangsan@qq.com'),
(2, '李四', 'lisi@qq.com');
INSERT INTO orders (user_id, amount, status) VALUES
(1, 500.00, 'paid'),
(1, 300.00, 'shipping'),
(1, 800.00, 'completed'),
(2, 200.00, 'pending');
-- 查询 1：查询用户的所有订单
SELECT o.*
FROM orders o
WHERE o.user_id = 1;
-- 查询 2：查询订单及对应的用户信息
SELECT o.*, u.username, u.email
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.id = 1;
-- 查询 3：统计每个用户的订单数量
SELECT u.username, COUNT(o.id) as order_count
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.id;
```
#### 3.2.4 数据样子
```
users 表（"一"的一方）：
┌────┬──────────┬─────────────────┐
│ id │ username │ email │
├────┼──────────┼─────────────────┤
│ 1 │ 张三 │ zhangsan@qq.com │
│ 2 │ 李四 │ lisi@qq.com │
└────┴──────────┴─────────────────┘
│
│ 一对多关系
│
orders 表（"多"的一方）：
┌────┬─────────┬────────┬───────────┐
│ id │ user_id │ amount │ status │
├────┼─────────┼────────┼───────────┤
│ 1 │ 1 │ 500.00 │ paid │ ← 张三的订单
│ 2 │ 1 │ 300.00 │ shipping │ ← 张三的订单
│ 3 │ 1 │ 800.00 │ completed │ ← 张三的订单
│ 4 │ 2 │ 200.00 │ pending │ ← 李四的订单
└────┴─────────┴────────┴───────────┘
```
#### 3.2.5 什么时候用一对多？
**适合使用的场景**：
- 父子关系：用户 → 订单、分类 → 商品
- 包含关系：文章 → 评论、部门 → 员工
- 层级关系：菜单 → 子菜单
**设计原则**：
- 在"多"的那张表添加外键
- 外键指向"一"的那张表的主键
- 使用 LEFT JOIN 可以查询"即使没有订单的用户"
::: tip 💡 一对多关系的判断标准
问自己："A 的一条记录能对应 B 的多条记录吗？"
- 如果能 → 可能是一对多
- 再问："B 的一条记录能对应 A 的多条记录吗？"
- 如果不能 → 确定是一对多
- 如果能 → 是多对多
:::
#### 3.3.1 什么是"多对多"？
**定义**：A 表的多条记录可以对应 B 表的多条记录，反过来也成立。
**生活类比**：
- 多个学生 ↔ 多门课程（一个学生可以选多门课，一门课可以被多个学生选）
- 多个顾客 ↔ 多个商品（一个顾客可以买多个商品，一个商品可以被多个顾客买）
- 多个作者 ↔ 多篇文章（一篇文章可以有多个作者，一个作者可以写多篇文章）
**这是最复杂的关系，需要使用"中间表"！**
#### 3.3.2 用生活场景理解
想象你在做一个**学生选课系统**：
**场景**：学生和课程
**需求**：
- 一个学生可以选多门课程
- 一门课程可以被多个学生选
**怎么设计数据库？**
**方案一：在学生表添加课程字段（错误）**
```
students 表：
| id | name | courses |
| 1 | 小明 | 1,2,3 |
| 2 | 小红 | 1,2 |
```
**问题**：
- 无法查询"选了数学 1 的所有学生"（需要字符串匹配，很慢）
- 无法建立外键约束
- 无法给"选课"添加额外信息（比如：选课时间、成绩）
**方案二：在课程表添加学生字段（同样错误）**
```
courses 表：
| id | title | students |
| 1 | 数学 | 1,2,3,4,5 |
```
**同样的问题**：查询慢、无法建立约束、无法添加额外信息。
**方案三：使用中间表（正确！）**
创建三张表：
1. students 表（学生）
2. courses 表（课程）
3. enrollments 表（选课记录，中间表）
**关系表示**：
```
students (M) ---- (M) courses
| |
| enrollments（中间表）
| | student_id | course_id |
```
#### 3.3.3 SQL 实现
```sql
-- 学生表
CREATE TABLE students (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(50) NOT NULL,
student_no VARCHAR(20) UNIQUE NOT NULL, -- 学号
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- 课程表
CREATE TABLE courses (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(100) NOT NULL,
credits DECIMAL(3, 1) NOT NULL, -- 学分
teacher VARCHAR(50)
);
-- 选课记录表（中间表）
CREATE TABLE enrollments (
student_id BIGINT NOT NULL,
course_id BIGINT NOT NULL,
enrolled_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, -- 选课时间
grade DECIMAL(5, 2), -- 成绩（可选）
PRIMARY KEY (student_id, course_id), -- 联合主键，防止重复选课
FOREIGN KEY (student_id) REFERENCES students(id) ON DELETE CASCADE,
FOREIGN KEY (course_id) REFERENCES courses(id) ON DELETE CASCADE
);
-- 插入数据
INSERT INTO students (id, name, student_no) VALUES
(1, '小明', '2021001'),
(2, '小红', '2021002'),
(3, '小刚', '2021003');
INSERT INTO courses (id, title, credits, teacher) VALUES
(1, '数学', 4.0, '王老师'),
(2, '英语', 3.0, '李老师'),
(3, '物理', 4.0, '张老师');
-- 学生选课
INSERT INTO enrollments (student_id, course_id) VALUES
(1, 1), -- 小明选了数学
(1, 2), -- 小明选了英语
(2, 1), -- 小红选了数学
(2, 3), -- 小红选了物理
(3, 2), -- 小刚选了英语
(3, 3); -- 小刚选了物理
-- 查询 1：查询小明选了哪些课程
SELECT c.*
FROM courses c
JOIN enrollments e ON c.id = e.course_id
WHERE e.student_id = 1;
-- 查询 2：查询数学课有哪些学生选了
SELECT s.*
FROM students s
JOIN enrollments e ON s.id = e.student_id
WHERE e.course_id = 1;
-- 查询 3：查询每个学生选了多少门课
SELECT s.name, COUNT(e.course_id) as course_count
FROM students s
LEFT JOIN enrollments e ON s.id = e.student_id
GROUP BY s.id;
-- 查询 4：录入成绩
UPDATE enrollments
SET grade = 90.5
WHERE student_id = 1 AND course_id = 1;
-- 查询 5：查询小明的选课及成绩
SELECT c.title, e.grade, e.enrolled_at
FROM courses c
JOIN enrollments e ON c.id = e.course_id
WHERE e.student_id = 1;
```
#### 3.3.4 数据样子
```
students 表：
┌────┬──────┬───────────┐
│ id │ name │ student_no│
├────┼──────┼───────────┤
│ 1 │ 小明 │ 2021001 │
│ 2 │ 小红 │ 2021002 │
│ 3 │ 小刚 │ 2021003 │
└────┴──────┴───────────┘
│ ┌──────────────┐
│ │ courses 表 │
│ ├────┬─────────┬────────┬────────┐
│ │ id │ title │ credits│ teacher│
│ ├────┼─────────┼────────┼────────┤
│ │ 1 │ 数学 │ 4.0 │ 王老师 │
│ │ 2 │ 英语 │ 3.0 │ 李老师 │
│ │ 3 │ 物理 │ 4.0 │ 张老师 │
│ └────┴─────────┴────────┴────────┘
│ ▲
│ │
│ │ 多对多关系
│ │
│ ┌───────────────────┐
│ │ enrollments（中间表）│
│ ├──────────┬─────────┬──────────────┬───────┐
│ │student_id│course_id│ enrolled_at │ grade │
│ ├──────────┼─────────┼──────────────┼───────┤
│ │ 1 │ 1 │ 2024-09-01 │ 90.5 │ ← 小明选数学
│ │ 1 │ 2 │ 2024-09-01 │ NULL │ ← 小明选英语
│ │ 2 │ 1 │ 2024-09-01 │ NULL │ ← 小红选数学
│ │ 2 │ 3 │ 2024-09-01 │ NULL │ ← 小红选物理
│ │ 3 │ 2 │ 2024-09-01 │ NULL │ ← 小刚选英语
│ │ 3 │ 3 │ 2024-09-01 │ NULL │ ← 小刚选物理
│ └──────────┴─────────┴──────────────┴───────┘
```
#### 3.3.5 中间表的设计要点
**要点 1：联合主键**
```sql
PRIMARY KEY (student_id, course_id)
```
作用：防止同一个学生重复选同一门课
**要点 2：外键约束**
```sql
FOREIGN KEY (student_id) REFERENCES students(id) ON DELETE CASCADE,
FOREIGN KEY (course_id) REFERENCES courses(id) ON DELETE CASCADE
```
作用：保证数据完整性
- 删除学生时，自动删除该学生的选课记录
- 删除课程时，自动删除该课程的选课记录
**要点 3：中间表可以添加额外字段**
```sql
enrolled_at TIMESTAMP, -- 选课时间
grade DECIMAL(5, 2), -- 成绩
status VARCHAR(20), -- 状态：选课中、已退课、已完成
```
这是多对多关系的一大优势！
#### 3.3.6 什么时候用多对多？
**适合使用的场景**：
- 标签系统：文章 ↔ 标签
- 权限系统：用户 ↔ 角色
- 社交关系：用户 ↔ 用户（关注、好友）
- 购物车：用户 ↔ 商品
**设计原则**：
- 必须创建中间表（也叫关联表、桥接表）
- 中间表包含两个外键，分别指向两张表
- 使用联合主键防止重复关联
- 可以在中间表添加额外属性（如：选课时间、成绩）
::: tip 💡 多对多关系的判断标准
问自己：
1. "A 的一条记录能对应 B 的多条记录吗？" → 是
2. "B 的一条记录能对应 A 的多条记录吗？" → 是
3. "A 和 B 之间的关联需要额外信息吗？" → 可能需要
如果 1 和 2 都是"是"，这就是多对多关系，需要用中间表！
:::
---
## 4. 范式理论：从混乱到有序
### 4.0 什么是"范式"？
**范式**（Normalization，规范化）是数据库设计的"规范"或"标准"。
**目的**：
- 消除数据冗余（重复的数据）
- 避免数据异常（插入、更新、删除时的问题）
- 让数据结构更清晰
**通俗理解**：
就像整理你的衣柜：
- 乱七八糟的衣服堆在一起 → 不符合范式
- 按类别分开（上衣、裤子、袜子）→ 符合第一范式
- 再按颜色分开 → 符合第二范式
- 再按季节分开 → 符合第三范式
**范式的级别**：
- 1NF（第一范式）：基础要求
- 2NF（第二范式）：在 1NF 基础上进一步优化
- 3NF（第三范式）：在 2NF 基础上再优化
- BCNF（BC 范式）：3NF 的增强版
- 4NF、5NF：更高级的范式（很少用到）
**实际开发中**：
- 大部分系统做到 3NF 就够了
- 有时为了性能，会故意违反范式（反范式化，后面会讲）
### 4.1 第一范式（1NF）：消除重复组
#### 4.1.1 1NF 的规则
**规则**：每个字段都应该是"原子性"的，不可再分。
**什么是不符合 1NF？**
- 一个字段包含多个值
- 一个字段包含"组合数据"（如：地址 = 城市 + 区 + 详细地址）
**什么是符合 1NF？**
- 每个字段只存储一个值
- 每个字段都是"最小数据单元"
#### 4.1.2 问题场景：订单信息重复
想象你在做一个**订单管理系统**：
**场景**：一个订单包含多个商品
**错误的表设计（不符合 1NF）**：
```sql
orders 表：
| id | user_id | products | total |
| 1 | 100 | iPhone(2台),iPad(1台),AirPods(3台) | 50000 |
```
**问题**：
1. `products` 字段包含多个值（不原子）
2. 无法查询"哪些订单包含 iPhone"
3. 无法统计"卖了多少台 iPad"
4. 修改商品数量需要字符串操作
5. 无法对商品建立索引
#### 4.1.3 应用 1NF 后
**方案 1：拆分成多行（符合 1NF）**
```sql
orders 表：
| id | user_id | product_id | product_name | quantity | price |
| 1 | 100 | 1 | iPhone | 2 | 5999 |
| 1 | 100 | 2 | iPad | 1 | 3999 |
| 1 | 100 | 3 | AirPods | 3 | 1299 |
```
**改进**：
- 每行只记录一个商品（原子性）
- 可以查询"哪些订单包含 iPhone"
- 可以统计"卖了多少台 iPad"
- 可以对 `product_id` 建立索引
**问题**：`user_id` 和 `id` 重复了（这是 2NF 要解决的问题）
#### 4.1.4 另一个例子：地址字段
**不符合 1NF**：
```sql
users 表：
| id | name | address |
| 1 | 张三 | 北京市朝阳区xxx街道 |
```
**问题**：`address` 包含多个信息（城市、区、详细地址），不原子。
**符合 1NF**：
```sql
users 表：
| id | name | city | district | detail_address |
| 1 | 张三 | 北京市 | 朝阳区 | xxx街道 |
```
**改进**：
- 每个字段只存储一个信息
- 可以按城市查询、按区统计
::: tip 💡 1NF 是基础
所有关系型数据库（MySQL、PostgreSQL、Oracle）默认都满足 1NF，因为字段本身就不能存储复杂对象（JSON 除外）。即使你违反了 1NF（如存储逗号分隔的字符串），数据库也不会报错，但会导致查询和维护困难。
:::
```sql
-- 用户和地址混在一起
| id | name | contact_info |
| 1 | 张三 | 北京朝阳区,13800138000 |
```
✅ **符合 1NF**：
```sql
| id | name | city | district | phone |
| 1 | 张三 | 北京 | 朝阳区 | 13800138000 |
```
::: tip 💡 1NF 是基础
所有关系型数据库（MySQL、PostgreSQL、Oracle）默认都满足 1NF，因为字段本身就不能存储复杂对象（JSON 除外）。即使你违反了 1NF（如存储逗号分隔的字符串），数据库也不会报错，但会导致查询和维护困难。
:::
### 4.2 第二范式（2NF）：消除部分依赖
#### 4.2.1 2NF 的规则
**前提**：表必须先符合 1NF
**规则**：非主键字段必须**完全依赖于**主键，而不是只依赖主键的一部分。
**什么是"部分依赖"？**
- 当主键是"复合主键"（多个字段组成的主键）时才存在
- 某个非主键字段只依赖主键的一部分，而不是全部
**什么是不符合 2NF？**
- 主键是复合主键（如：order_id + product_id）
- 某个字段（如 product_name）只依赖 product_id，不依赖 order_id
**什么是符合 2NF？**
- 消除部分依赖
- 所有非主键字段都完全依赖主键
#### 4.2.2 问题场景：订单明细表
想象你在设计**订单明细表**：
**场景**：记录每个订单的每个商品
**表设计**：
```sql
order_items 表（订单明细）：
| order_id | product_id | product_name | quantity | unit_price | subtotal |
| 100 | 1 | iPhone | 2 | 5999 | 11998 |
| 100 | 2 | iPad | 1 | 3999 | 3999 |
```
**主键**：(order_id, product_id) —— 复合主键
**问题分析**：
| 字段 | 依赖关系 | 是否符合 2NF |
|:-----|:---------|:------------|
| quantity | 依赖 (order_id, product_id) | ✅ 符合 |
| subtotal | 依赖 (order_id, product_id) | ✅ 符合 |
| product_name | 只依赖 product_id | ❌ 不符合 |
| unit_price | 只依赖 product_id | ❌ 不符合 |
**为什么不符合？**
- `product_name` 只依赖 `product_id`
- 即使我改变 `order_id`，`product_name` 也不会变
- 这就是"部分依赖"（只依赖主键的一部分）
#### 4.2.3 会有什么问题？
**问题 1：数据冗余**
```sql
| order_id | product_id | product_name | quantity |
| 100 | 1 | iPhone | 2 |
| 101 | 1 | iPhone | 5 | ← 重复了
| 102 | 1 | iPhone | 1 | ← 又重复了
```
每次订购 iPhone，都要重复存储 `product_name`。
**问题 2：更新异常**
如果 iPhone 改名为 "iPhone 15"，需要更新所有包含该产品的订单记录。
**问题 3：插入异常**
无法插入一个还没有被订购的新产品（因为 order_id 不能为空）。
#### 4.2.4 应用 2NF 后
**方案：拆分成两张表**
```sql
-- 订单明细表（只依赖复合主键）
order_items 表：
| order_id | product_id | quantity | subtotal |
| 100 | 1 | 2 | 11998 |
| 100 | 2 | 1 | 3999 |
| 101 | 1 | 5 | 29995 |
-- 商品表（只依赖 product_id）
products 表：
| product_id | product_name | unit_price |
| 1 | iPhone | 5999 |
| 2 | iPad | 3999 |
```
**改进**：
- `product_name` 和 `unit_price` 只在 products 表存储一次
- 修改商品信息时，只需更新 products 表
- 新商品可以先插入 products 表，即使还没人买
#### 4.2.5 查询数据
**查询订单 100 的所有商品详情**：
```sql
SELECT
oi.order_id,
oi.product_id,
p.product_name,
oi.quantity,
oi.subtotal
FROM order_items oi
JOIN products p ON oi.product_id = p.product_id
WHERE oi.order_id = 100;
```
虽然需要 JOIN，但数据结构更合理，避免了冗余和异常。
::: tip 💡 2NF 针对复合主键
如果主键是单个字段，则自动满足 2NF。2NF 主要解决复合主键的部分依赖问题。
**判断方法**：
- 主键是单个字段？ → 自动满足 2NF
- 主键是复合主键？ → 检查是否有字段只依赖主键的一部分
:::
### 4.3 第三范式（3NF）：消除传递依赖
#### 4.3.1 3NF 的规则
**前提**：表必须先符合 2NF
**规则**：非主键字段不**传递依赖**于主键。
**什么是"传递依赖"？**
- A → B → C
- C 依赖 B，B 依赖 A
- 所以 C 传递依赖 A
**什么是不符合 3NF？**
- 非主键字段之间有依赖关系
- 比如：user_level 依赖 user_id，而 user_id 又依赖 id
**什么是符合 3NF？**
- 所有非主键字段只直接依赖主键
- 非主键字段之间没有依赖关系
#### 4.3.2 问题场景：订单表包含用户等级
想象你在设计**订单表**：
**场景**：记录订单时，需要记录用户的等级（用于计算折扣）
**表设计**：
```sql
orders 表：
| id | user_id | total | user_level | discount | pay_amount |
| 1 | 100 | 500 | VIP | 0.9 | 450 |
| 2 | 101 | 300 | 普通 | 1.0 | 300 |
```
**主键**：id
**问题分析**：
| 字段 | 依赖关系 | 是否符合 3NF |
|:-----|:---------|:------------|
| total | 直接依赖 id | ✅ 符合 |
| user_id | 直接依赖 id | ✅ 符合 |
| user_level | 依赖 user_id，再依赖 id | ❌ 不符合（传递依赖） |
| discount | 依赖 user_level | ❌ 不符合（传递依赖） |
**为什么不符合？**
- `user_level` 依赖 `user_id`（用户的等级存在用户表中）
- `user_id` 依赖 `id`（订单属于用户）
- 所以 `user_level` 传递依赖 `id`
- 同理，`discount` 依赖 `user_level`，也传递依赖 `id`
#### 4.3.3 会有什么问题？
**问题 1：数据冗余**
```sql
| id | user_id | user_level | discount |
| 1 | 100 | VIP | 0.9 |
| 2 | 100 | VIP | 0.9 | ← 重复了
| 3 | 100 | VIP | 0.9 | ← 又重复了
```
同一用户的多个订单，重复存储 `user_level` 和 `discount`。
**问题 2：更新异常**
如果用户从"VIP"升级到"SVIP"，需要更新该用户的所有历史订单。
**问题 3：数据不一致**
```sql
| id | user_id | user_level | discount |
| 1 | 100 | VIP | 0.9 |
| 2 | 100 | SVIP | 0.8 | ← 不一致！
```
同一用户的不同订单，等级可能不同（数据更新不一致）。
#### 4.3.4 应用 3NF 后
**方案：把用户等级放到用户表**
```sql
-- 订单表（只存储订单相关字段）
orders 表：
| id | user_id | total | discount | pay_amount |
| 1 | 100 | 500 | 0.9 | 450 |
| 2 | 100 | 300 | 0.9 | 270 |
-- 用户表（存储用户等级）
users 表：
| id | username | level |
| 100 | 张三 | VIP |
```
**改进**：
- `user_level` 只在 users 表存储一次
- 修改用户等级时，只需更新 users 表
- 订单表只存储 `discount`（下单时的折扣），作为历史记录
::: tip 💡 3NF 与历史数据
有些场景需要"冗余"历史数据：
- 订单的折扣（下单时的折扣，即使后来用户等级变了）
- 商品的快照（下单时的价格，即使后来商品改价了）
这不是违反 3NF，而是为了"历史准确性"故意保留的冗余。
:::
#### 4.3.5 另一个例子：员工表
**不符合 3NF**：
```sql
employees 表：
| id | name | dept_id | dept_name | dept_location |
| 1 | 张三 | 10 | 技术部 | 北京 |
| 2 | 李四 | 10 | 技术部 | 北京 | ← 重复
| 3 | 王五 | 20 | 销售部 | 上海 |
| 4 | 赵六 | 20 | 销售部 | 上海 | ← 重复
```
**问题**：`dept_name` 和 `dept_location` 依赖 `dept_id`，再依赖 `id`（传递依赖）
**符合 3NF**：
```sql
-- 员工表
employees 表：
| id | name | dept_id |
| 1 | 张三 | 10 |
| 2 | 李四 | 10 |
| 3 | 王五 | 20 |
-- 部门表
departments 表：
| dept_id | dept_name | dept_location |
| 10 | 技术部 | 北京 |
| 20 | 销售部 | 上海 |
```
::: tip 💡 3NF 是最常见的范式
实际业务中，大部分表设计都遵循 3NF，它在数据冗余和查询性能之间取得了平衡。
**判断方法**：
- 非主键字段之间有依赖关系吗？ → 有，可能不符合 3NF
- 这个依赖是"历史快照"还是"可以外键关联"？ → 可以外键关联，应该拆分
:::
```sql
-- 订单明细表：(order_id, product_id) 是复合主键
| order_id | product_id | product_name | quantity | unit_price |
| 100 | 1 | iPhone | 2 | 5999 |
```
**问题**：`product_name` 和 `unit_price` 只依赖 `product_id`，不依赖 `order_id`。
✅ **符合 2NF**：
```sql
-- 订单明细表
| order_id | product_id | quantity |
| 100 | 1 | 2 |
-- 商品表
| product_id | name | price |
| 1 | iPhone | 5999 |
```
::: tip 💡 2NF 针对复合主键
如果主键是单个字段，则自动满足 2NF。2NF 主要解决复合主键的部分依赖问题。
:::
### 4.3 第三范式（3NF）：消除传递依赖
**要求**：非主键字段不传递依赖于主键。
❌ **不符合 3NF**：
```sql
-- 订单表
| id | user_id | total | user_level | discount |
| 1 | 100 | 500 | VIP | 0.9 |
```
**问题**：`user_level` 依赖 `user_id`，再依赖 `id`（传递依赖）。
✅ **符合 3NF**：
```sql
-- 订单表
| id | user_id | total | discount |
| 1 | 100 | 500 | 0.9 |
-- 用户表
| id | level |
| 100| VIP |
```
::: tip 💡 3NF 是最常见的范式
实际业务中，大部分表设计都遵循 3NF，它在数据冗余和查询性能之间取得了平衡。
:::
### 4.4 范式对比演示
👇 **点击下方标签页，查看各范式的对比**：
---
## 5. 反范式化：用空间换时间
**范式化**虽然能消除冗余，但查询时需要多次 JOIN，影响性能。
**反范式化**（Denormalization）是有意增加冗余，换取查询性能提升。
### 5.1 何时需要反范式化？
| 场景 | 说明 |
| :--- | :--- |
| **高频查询** | 每秒数百次查询，JOIN 成为瓶颈 |
| **大数据量** | 表数据超过千万级，JOIN 性能下降 |
| **报表统计** | 需要聚合计算，预先存储结果 |
| **分布式系统** | 跨库 JOIN 困难，需要冗余数据 |
### 5.2 反范式化实战
**场景**：电商订单查询
**范式化设计**：
```sql
-- 订单表
orders (id, user_id, total, status)
users (id, name, email)
-- 查询订单及用户信息
SELECT o.*, u.name, u.email
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.id = 123;
```
**性能问题**：每次查询都需要 JOIN，数据量大时慢。
**反范式化设计**：
```sql
-- 订单表（冗余用户信息）
orders (id, user_id, user_name, user_email, total, status)
-- 查询订单（单表查询）
SELECT * FROM orders WHERE id = 123;
```
**性能提升**：无需 JOIN，单表查询速度快 5-10 倍。
**代价**：
- 存储空间增加（每个订单多存用户名和邮箱）
- 更新成本增加（修改用户邮箱需更新所有历史订单）
### 5.3 反范式化的设计原则
| 原则 | 说明 |
| :--- | :--- |
| **冗余不经常变化的数据** | 如用户名、商品名称（很少修改） |
| **冗余查询频繁的字段** | 如订单列表展示的用户名、商品图片 |
| **保留原始表** | 范式化表作为"主表"，反范式化表作为"查询表" |
| **数据同步策略** | 通过定时任务、消息队列同步冗余字段 |
::: warning ⚠️ 反范式化的风险
- 数据冗余：占用更多存储空间
- 更新异常：修改数据需同步多处
- 数据不一致：同步失败导致数据不匹配
**建议**：核心交易表保持范式化，查询表、统计表适当反范式化。
:::
---
## 6. 常见反模式及改进
**反模式**（Antipattern）是"看似正确但实际有害"的设计模式。
就像生活中的"误区"：
- 为了省钱买便宜的鞋子 → 结果经常坏，花更多钱
- 为了省时间不睡觉 → 结果身体垮了，效率更低
数据库设计也有很多"反模式"，看起来方便，实际上埋雷。
### 6.1 反模式 1：巨型宽表
#### 6.1.1 错误的做法
**错误设计**：把所有数据塞进一张表
```sql
-- 巨型宽表（错误示例）
CREATE TABLE big_table (
id BIGINT,
-- 用户字段
user_name VARCHAR(50),
user_email VARCHAR(100),
user_phone VARCHAR(20),
-- 订单字段（重复 100 次！）
order_1_id BIGINT,
order_1_amount DECIMAL(10, 2),
order_1_status VARCHAR(20),
order_2_id BIGINT,
order_2_amount DECIMAL(10, 2),
order_2_status VARCHAR(20),
-- ...
order_100_id BIGINT,
order_100_amount DECIMAL(10, 2),
order_100_status VARCHAR(20)
);
-- 数据样子
| id | user_name | user_email | order_1_id | order_1_amount | order_2_id | order_2_amount | ... |
| 1 | 张三 | zhang@qq.com | 100 | 500.00 | 101 | 300.00 | ... |
```
#### 6.1.2 为什么会这样做？
**当时的需求**：
- 产品经理说："我们想在一个页面显示用户的所有订单"
- 开发者想："少 JOIN 几次，查询更快"
- 时间紧："先赶上线，以后再优化"
**看起来很合理**：
- 查询用户订单时，不需要 JOIN，单表查询快
- SQL 简单：`SELECT * FROM big_table WHERE id = 1`
#### 6.1.3 会有什么问题？
**问题 1：字段数量爆炸**
```sql
-- MySQL 对表字段数量有限制
-- InnoDB: 最多 1017 列
-- MyISAM: 最多 259 列
-- 如果用户下了 1000 个订单怎么办？
order_1_id, order_2_id, ..., order_1000_id ← 字段爆炸！
```
**问题 2：大量空值，浪费存储**
```sql
-- 大部分用户只有 5-10 个订单，其他 90-95 个字段都是 NULL
| id | order_1_amount | order_2_amount | order_3_amount | ... | order_100_amount |
| 1 | 500.00 | 300.00 | 800.00 | ... | NULL | ← 浪费 97 个字段
```
**存储浪费**：
- 假设每个字段占用 8 字节（DECIMAL(10,2)）
- 100 个字段 × 8 字节 = 800 字节/行
- 实际只用 3 个字段 = 24 字节
- 浪费了 97% 的存储空间！
**问题 3：新增订单需要修改表结构（DDL 操作）**
```sql
-- 用户下了第 101 个订单，需要加字段
ALTER TABLE big_table ADD COLUMN order_101_id BIGINT;
ALTER TABLE big_table ADD COLUMN order_101_amount DECIMAL(10, 2);
-- 问题：
-- 1. DDL 操作会锁表，影响线上服务
-- 2. 大表加字段非常慢（可能需要几小时）
-- 3. 需要停机维护，用户体验差
```
**问题 4：无法查询"某个订单的所有信息"**
```sql
-- 想查询订单 100 的信息
-- 需要扫描所有 order_XX_id 字段
SELECT *
FROM big_table
WHERE order_1_id = 100
OR order_2_id = 100
OR order_3_id = 100
-- ...
OR order_100_id = 100; ← SQL 非常复杂，性能极差！
```
**问题 5：无法统计订单数据**
```sql
-- 想统计"所有订单的总金额"
-- 需要写复杂的 SQL
SELECT
SUM(order_1_amount) +
SUM(order_2_amount) +
-- ...
SUM(order_100_amount) as total ← 无法维护！
FROM big_table;
```
#### 6.1.4 正确的做法
**正确设计**：拆分成多张表，用外键关联
```sql
-- 用户表
CREATE TABLE users (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(50) NOT NULL,
email VARCHAR(100) UNIQUE NOT NULL,
phone VARCHAR(20),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- 订单表
CREATE TABLE orders (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
user_id BIGINT NOT NULL, -- 外键，指向 users 表
amount DECIMAL(10, 2) NOT NULL,
status VARCHAR(20) DEFAULT 'pending',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);
-- 创建索引（提升查询性能）
CREATE INDEX idx_orders_user_id ON orders(user_id);
```
#### 6.1.5 数据样子
```sql
-- users 表
| id | name | email | phone |
| 1 | 张三 | zhang@qq.com | 13800138000 |
-- orders 表
| id | user_id | amount | status | created_at |
| 100 | 1 | 500.00 | paid | 2024-01-01 10:00:00|
| 101 | 1 | 300.00 | shipping | 2024-01-05 14:30:00|
| 102 | 1 | 800.00 | completed| 2024-01-10 09:15:00|
```
#### 6.1.6 查询数据
**查询用户的所有订单**：
```sql
SELECT o.*
FROM orders o
WHERE o.user_id = 1; -- 利用索引，快速查询
```
**查询订单及对应的用户信息**：
```sql
SELECT o.*, u.name, u.email
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.id = 100; -- 只 JOIN 需要的字段
```
**统计用户的订单总数和总金额**：
```sql
SELECT
u.name,
COUNT(o.id) as order_count,
SUM(o.amount) as total_amount
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.id;
```
#### 6.1.7 优缺点对比
| 对比项 | 宽表（错误） | 分表（正确） |
|:-----|:-----------|:-----------|
| **存储空间** | 大量空值，浪费 90%+ | 紧凑存储，无浪费 |
| **扩展性** | 需要修改表结构（DDL） | 直接 INSERT，无需改表 |
| **查询性能** | 简单查询快，复杂查询极慢 | 利用索引，整体性能好 |
| **维护性** | 字段数量爆炸，无法维护 | 结构清晰，易于维护 |
| **数据完整性** | 无法建立外键约束 | 外键保证数据一致 |
**结论**：**不要用宽表！用一对多关系 + 索引来解决！**
---
### 6.2 反模式 2：逗号分隔值
#### 6.2.1 错误的做法
**错误设计**：用逗号分隔存储多个值
```sql
-- 文章表（错误示例）
CREATE TABLE posts (
id BIGINT PRIMARY KEY,
title VARCHAR(200),
content TEXT,
tags VARCHAR(500) -- 用逗号分隔存储标签
);
-- 数据样子
| id | title | tags |
| 1 | Vue入门 | vue,frontend,javascript |
| 2 | React实战 | react,frontend |
| 3 | Node.js后端 | node,backend |
```
#### 6.2.2 为什么会这样做？
**当时的需求**：
- 产品经理说："一篇文章可以有多个标签"
- 开发者想："用逗号分隔最简单，不用建中间表"
- 时间紧："先赶上线，以后再优化"
**看起来很合理**：
- 存储简单：直接 `'vue,frontend,javascript'`
- 查询简单：`SELECT * FROM posts WHERE id = 1`
- 不用 JOIN：少一张表，少麻烦
#### 6.2.3 会有什么问题？
**问题 1：无法有效索引**
```sql
-- 即使给 tags 字段建索引
CREATE INDEX idx_tags ON posts(tags);
-- 查询包含 "vue" 标签的文章
SELECT * FROM posts WHERE tags LIKE '%vue%';
-- 问题：
-- 1. LIKE '%xxx%' 无法使用索引（全表扫描）
-- 2. 查询 "vue" 会匹配 "javascript"（包含 "vue" 字符）
-- 3. 性能极差，数据量大时数据库卡死
```
**问题 2：无法精确查询**
```sql
-- 想查询"有哪些文章包含 frontend 标签"
SELECT * FROM posts WHERE tags LIKE '%frontend%';
-- 问题：会匹配到错误的记录
-- 'vue,frontend,javascript' ← 正确
-- 'frontendend' ← 错误！但会被匹配到
-- 'myfrontendapp' ← 错误！但会被匹配到
```
**问题 3：无法统计查询**
```sql
-- 想统计"每个标签有多少篇文章"
-- 几乎无法用 SQL 实现！
-- 需要：
-- 1. 查出所有文章
-- 2. 在应用层分割 tags 字符串
-- 3. 手动统计
-- 或者用复杂的 SQL（性能极差）
SELECT
SUBSTRING_INDEX(SUBSTRING_INDEX(tags, ',', n), ',', -1) as tag,
COUNT(*) as count
FROM posts
JOIN (
SELECT 1 as n UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4
) numbers
ON CHAR_LENGTH(tags) - CHAR_LENGTH(REPLACE(tags, ',', '')) >= n - 1
GROUP BY tag;
```
**问题 4：无法关联查询**
```sql
-- 想查询"包含 vue 标签的文章 + 作者信息"
-- 需要字符串匹配，无法用 JOIN
SELECT p.*, u.name
FROM posts p
JOIN users u ON p.user_id = u.id
WHERE p.tags LIKE '%vue%'; ← 性能差，不准确
```
**问题 5：修改标签需要字符串操作**
```sql
-- 想给文章 1 添加一个 "tutorial" 标签
-- 需要分步操作
-- 1. 查询当前 tags
SELECT tags FROM posts WHERE id = 1; -- 'vue,frontend,javascript'
-- 2. 在应用层拼接字符串
new_tags = old_tags + ',tutorial' -- 'vue,frontend,javascript,tutorial'
-- 3. 更新数据库
UPDATE posts SET tags = 'vue,frontend,javascript,tutorial' WHERE id = 1;
-- 问题：
-- 1. 需要 3 步操作，代码复杂
-- 2. 并发修改时可能丢失数据
-- 3. 无法保证标签唯一性（可能添加重复标签）
```
#### 6.2.4 正确的做法
**正确设计**：用中间表（多对多关系）
```sql
-- 文章表
CREATE TABLE posts (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(200) NOT NULL,
content TEXT,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- 标签表
CREATE TABLE tags (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(50) UNIQUE NOT NULL -- 标签名称唯一
);
-- 文章-标签关联表（中间表）
CREATE TABLE post_tags (
post_id BIGINT NOT NULL,
tag_id BIGINT NOT NULL,
PRIMARY KEY (post_id, tag_id), -- 联合主键，防止重复关联
FOREIGN KEY (post_id) REFERENCES posts(id) ON DELETE CASCADE,
FOREIGN KEY (tag_id) REFERENCES tags(id) ON DELETE CASCADE
);
-- 创建索引（提升查询性能）
CREATE INDEX idx_post_tags_tag_id ON post_tags(tag_id);
```
#### 6.2.5 数据样子
```sql
-- posts 表
| id | title | content |
| 1 | Vue入门 | Vue 是一个渐进式框架... |
| 2 | React实战| React 是一个 UI 库... |
-- tags 表
| id | name |
| 1 | vue |
| 2 | frontend |
| 3 | javascript |
| 4 | react |
-- post_tags 表
| post_id | tag_id |
| 1 | 1 | ← 文章 1 有 vue 标签
| 1 | 2 | ← 文章 1 有 frontend 标签
| 1 | 3 | ← 文章 1 有 javascript 标签
| 2 | 2 | ← 文章 2 有 frontend 标签
| 2 | 4 | ← 文章 2 有 react 标签
```
#### 6.2.6 查询数据
**查询包含 "vue" 标签的所有文章**：
```sql
SELECT p.*
FROM posts p
JOIN post_tags pt ON p.id = pt.post_id
JOIN tags t ON pt.tag_id = t.id
WHERE t.name = 'vue'; -- 利用索引，快速查询
```
**查询文章的所有标签**：
```sql
SELECT t.name
FROM tags t
JOIN post_tags pt ON t.id = pt.tag_id
WHERE pt.post_id = 1;
-- 结果
| name |
| vue |
| frontend |
| javascript |
```
**统计每个标签的文章数量**：
```sql
SELECT t.name, COUNT(pt.post_id) as post_count
FROM tags t
LEFT JOIN post_tags pt ON t.id = pt.tag_id
GROUP BY t.id
ORDER BY post_count DESC;
-- 结果
| name | post_count |
| frontend | 2 |
| vue | 1 |
| javascript | 1 |
| react | 1 |
```
**给文章添加标签**：
```sql
-- 先查询或创建标签
INSERT IGNORE INTO tags (name) VALUES ('tutorial');
-- 添加关联
INSERT INTO post_tags (post_id, tag_id)
VALUES (1, (SELECT id FROM tags WHERE name = 'tutorial'));
-- 完事！一条 SQL 搞定
```
#### 6.2.7 优缺点对比
| 对比项 | 逗号分隔（错误） | 中间表（正确） |
|:-----|:--------------|:-------------|
| **查询性能** | 无法使用索引，全表扫描 | 利用索引，快速查询 |
| **查询精确度** | LIKE 匹配不准确 | 精确匹配 |
| **统计查询** | 几乎无法实现 | 简单的 GROUP BY |
| **数据完整性** | 无约束，可重复、格式混乱 | 外键 + 唯一约束 |
| **维护性** | 字符串操作，复杂 | 标准 SQL，简单 |
| **扩展性** | 难以扩展（如标签权重） | 易于扩展 |
**结论**：**不要用逗号分隔！用多对多关系 + 中间表来解决！**
---
### 6.3 反模式 3：滥用 JSON 字段
#### 6.3.1 错误的做法
**错误设计**：把订单明细存为 JSON
```sql
-- 订单表（错误示例）
CREATE TABLE orders (
id BIGINT PRIMARY KEY,
user_id BIGINT,
items JSON, -- 订单明细存为 JSON
total DECIMAL(10, 2),
created_at TIMESTAMP
);
-- 数据样子
| id | user_id | items | total |
| 1 | 100 | [{"pid":1,"qty":2},{"pid":2,"qty":1}] | 500 |
| 2 | 101 | [{"pid":3,"qty":5}] | 300 |
```
#### 6.3.2 为什么会这样做？
**当时的需求**：
- 产品经理说："订单明细结构复杂，字段不固定"
- 开发者想："JSON 灵活，不用定义字段"
- 时间紧："先赶上线，以后再优化"
**看起来很合理**：
- 灵活：可以存储任意结构的数据
- 简单：不需要建 order_items 表
- 查询快：单表查询，不需要 JOIN
#### 6.3.3 会有什么问题？
**问题 1：无法建立外键约束**
```sql
-- 无法保证 JSON 中的 pid（商品 ID）真实存在
INSERT INTO orders (id, user_id, items, total) VALUES
(1, 100, '[{"pid":9999,"qty":1}]', 500); ← pid 9999 不存在，但能插入！
-- 问题：数据完整性无法保证
```
**问题 2：无法有效索引（MySQL 5.7 之前）**
```sql
-- MySQL 5.7+ 支持生成列 + 索引，但很复杂
-- MySQL 5.6 及之前版本，JSON 字段完全无法索引
-- 查询"购买了商品 1 的所有订单"
SELECT * FROM orders
WHERE JSON_CONTAINS(items, '{"pid": 1}'); ← 全表扫描！
```
**问题 3：数据完整性差**
```sql
-- 可以插入错误格式的 JSON
INSERT INTO orders (id, user_id, items, total) VALUES
(1, 100, '[{"pid":1}]', 500), -- 缺少 qty
(2, 100, '[{"qty":2}]', 300), -- 缺少 pid
(3, 100, 'not-a-json', 200); -- 不是 JSON
-- 问题：数据库无法检测 JSON 内容的正确性
```
**问题 4：查询"某个商品的所有订单"需要全文扫描**
```sql
-- 想查询"购买了 iPhone 的所有订单"
-- 需要扫描所有订单的 JSON 字段
SELECT * FROM orders
WHERE JSON_CONTAINS(items, '{"pid": 1}'); ← 全表扫描，性能极差！
```
**问题 5：修改商品信息很困难**
```sql
-- 想把商品 1 的名称从 "iPhone" 改为 "iPhone 15"
-- 需要更新所有包含该商品的订单的 JSON 字段
-- 但 JSON 无法用 UPDATE 语句部分更新，只能整体替换
-- 步骤：
-- 1. 查询订单
SELECT items FROM orders WHERE id = 1;
-- 2. 在应用层解析 JSON，修改，再序列化
items = JSON.parse(items)
items.forEach(item => {
if (item.pid === 1) {
item.name = "iPhone 15" -- 但订单表没存 name！
}
})
new_items = JSON.stringify(items)
-- 3. 更新数据库
UPDATE orders SET items = new_items WHERE id = 1;
-- 问题：操作复杂，性能差，容易出错
```
**问题 6：无法统计商品销量**
```sql
-- 想统计"每个商品卖了多少"
-- 需要在应用层遍历所有订单的 JSON
-- 或用复杂的 SQL（MySQL 5.7+）
SELECT
JSON_UNQUOTE(JSON_EXTRACT(items, '$[0].pid')) as pid,
SUM(JSON_EXTRACT(items, '$[0].qty')) as total_qty
FROM orders
GROUP BY pid; ← 假设每个订单只有一个商品，不通用！
```
#### 6.3.4 正确的做法
**正确设计**：用关联表（一对多关系）
```sql
-- 订单表
CREATE TABLE orders (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
user_id BIGINT NOT NULL,
total DECIMAL(10, 2) NOT NULL,
status VARCHAR(20) DEFAULT 'pending',
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(id)
);
-- 订单明细表
CREATE TABLE order_items (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
order_id BIGINT NOT NULL, -- 外键，指向 orders 表
product_id BIGINT NOT NULL, -- 外键，指向 products 表
product_name VARCHAR(200), -- 冗余，保存下单时的商品名称
price DECIMAL(10, 2) NOT NULL, -- 冗余，保存下单时的价格
quantity INT NOT NULL,
subtotal DECIMAL(10, 2) NOT NULL, -- 小计 = price * quantity
FOREIGN KEY (order_id) REFERENCES orders(id) ON DELETE CASCADE,
FOREIGN KEY (product_id) REFERENCES products(id)
);
-- 创建索引（提升查询性能）
CREATE INDEX idx_order_items_order_id ON order_items(order_id);
CREATE INDEX idx_order_items_product_id ON order_items(product_id);
```
#### 6.3.5 数据样子
```sql
-- orders 表
| id | user_id | total | status | created_at |
| 1 | 100 | 500.00| paid | 2024-01-01 10:00:00|
-- order_items 表
| id | order_id | product_id | product_name | price | quantity | subtotal|
| 1 | 1 | 1 | iPhone | 5999.00| 2 | 11998.00|
| 2 | 1 | 2 | iPad | 3999.00| 1 | 3999.00 |
```
#### 6.3.6 查询数据
**查询订单的所有商品**：
```sql
SELECT oi.*
FROM order_items oi
WHERE oi.order_id = 1; -- 利用索引，快速查询
```
**查询"购买了商品 1 的所有订单"**：
```sql
SELECT DISTINCT o.*
FROM orders o
JOIN order_items oi ON o.id = oi.order_id
WHERE oi.product_id = 1; -- 利用索引，快速查询
```
**统计每个商品的销量**：
```sql
SELECT
p.name,
SUM(oi.quantity) as total_qty,
SUM(oi.subtotal) as total_amount
FROM products p
JOIN order_items oi ON p.id = oi.product_id
GROUP BY p.id
ORDER BY total_qty DESC;
```
#### 6.3.7 什么时候可以用 JSON？
JSON 不是"洪水猛兽"，在以下场景可以使用：
**适合使用 JSON 的场景**：
1. **非结构化数据**
```sql
-- 用户的扩展配置信息（每个用户配置不同）
ALTER TABLE users ADD COLUMN preferences JSON;
-- 数据样子
| id | username | preferences |
| 1 | zhangsan | {"theme":"dark","lang":"zh","fontSize":14} |
| 2 | lisi | {"theme":"light","lang":"en"} |
```
2. **低频查询的数据**
```sql
-- 日志、埋点数据（查询频率低）
CREATE TABLE events (
id BIGINT PRIMARY KEY,
user_id BIGINT,
event_data JSON, -- 事件详情（字段不固定）
created_at TIMESTAMP
);
```
3. **动态属性**
```sql
-- 商品的动态属性（不同品类属性不同）
-- 手机：屏幕尺寸、电池容量
-- 衣服：尺码、材质、颜色
CREATE TABLE products (
id BIGINT PRIMARY KEY,
name VARCHAR(200),
attributes JSON -- 动态属性
);
-- 数据样子
| id | name | attributes |
| 1 | iPhone | {"screen":"6.1 inch","battery":"3000mAh"} |
| 2 | T恤 | {"size":"L","material":"cotton","color":"blue"} |
```
**不适合使用 JSON 的场景**：
- 核心业务数据（订单、用户、商品）
- 需要频繁查询的字段
- 需要建立索引的字段
- 需要保证数据完整性的字段（外键约束）
::: tip 💡 JSON 的使用原则
**能用关系表就用关系表，实在不行才用 JSON。**
判断标准：
1. 这个字段需要查询吗？ → 需要，别用 JSON
2. 这个字段需要建立索引吗？ → 需要，别用 JSON
3. 这个字段需要保证数据完整性吗？ → 需要，别用 JSON
4. 这个字段结构经常变化吗？ → 是，可以考虑 JSON
:::
---
## 7. 实战：电商系统数据模型
下面是一个完整的电商系统数据模型设计。
### 7.1 核心模块
**用户模块**：
```sql
-- 用户表
users (id, username, email, password_hash, created_at)
-- 用户地址表
user_addresses (id, user_id, province, city, district, detail, is_default)
-- 用户资料表
user_profiles (id, user_id, nickname, avatar, bio)
```
**商品模块**：
```sql
-- 分类表
categories (id, name, parent_id, level)
-- 商品表
products (id, category_id, name, description, created_at)
-- 商品 SKU 表
product_skus (id, product_id, specs, price, stock)
-- 库存表
product_inventory (sku_id, warehouse_id, quantity)
```
**订单模块**：
```sql
-- 订单表
orders (
id,
user_id,
user_name, -- 冗余，反范式化
total_amount,
discount_amount,
pay_amount,
status,
created_at
)
-- 订单明细表
order_items (
id,
order_id,
product_id,
product_name, -- 冗余，反范式化
product_sku_id,
price,
quantity
)
-- 支付记录表
payments (id, order_id, amount, method, status, transaction_id)
```
**营销模块**：
```sql
-- 优惠券表
coupons (id, name, type, discount, min_amount, stock)
-- 用户优惠券表
user_coupons (id, user_id, coupon_id, status, used_at)
-- 促销活动表
promotions (id, name, type, discount, start_time, end_time)
```
### 7.2 关系设计
| 关系 | 类型 | 说明 |
| :--- | :--- | :--- |
| users ↔ orders | 1:N | 一个用户有多个订单 |
| orders ↔ order_items | 1:N | 一个订单有多个明细 |
| products ↔ product_skus | 1:N | 一个商品有多个 SKU |
| users & coupons | M:N | 通过 user_coupons 中间表 |
| products & categories | M:N | 一个商品可属于多个分类 |
### 7.3 反范式化策略
| 字段 | 冗余位置 | 原因 |
| :--- | :--- | :--- |
| user_name | orders 表 | 避免查询订单时 JOIN users 表 |
| product_name | order_items 表 | 避免商品改名后历史订单显示问题 |
| product_price | order_items 表 | 保存下单时价格，避免价格变动影响 |
---
## 8. 数据模型设计流程
### 8.0 手把手：从零设计一个数据模型
让我们用一个**图书馆管理系统**的例子，从头到尾演示数据模型设计过程。
#### 第一步：识别实体（识别"对象"）
**问题**：这个系统需要管理哪些"东西"？
**需求分析**：
- 图书馆有很多书
- 书有不同的类别（小说、科技、历史）
- 读者可以借书、还书
- 每本书可以被多次借阅
**识别出的实体**：
1. **图书**（Book）：书的基本信息
2. **读者**（Reader）：借书的人
3. **借阅记录**（Borrow）：谁借了哪本书
4. **分类**（Category）：书的分类
#### 第二步：确定属性（识别"特征"）
**问题**：每个实体有哪些信息需要记录？
**图书的属性**：
- 书名（title）
- 作者（author）
- ISBN（isbn）- 唯一标识
- 出版社（publisher）
- 出版年份（publish_year）
- 库存数量（stock）
**读者的属性**：
- 姓名（name）
- 电话（phone）
- 邮箱（email）
- 注册日期（registered_at）
**借阅记录的属性**：
- 借阅日期（borrowed_at）
- 应还日期（due_date）
- 实还日期（returned_at）
- 状态（status）：借阅中、已归还、逾期
**分类的属性**：
- 分类名称（name）
- 分类描述（description）
#### 第三步：确定关系（识别"关联"）
**问题**：这些实体之间有什么关系？
**分析**：
1. **图书 ↔ 读者**：多对多？
- 一个读者可以借多本书
- 一本书可以被多个读者借（不同时间）
- **但是**：同一时间，一本书只能被一个读者借
- **所以**：需要**借阅记录**来记录"谁借了哪本书"
2. **图书 ↔ 分类**：多对多
- 一本书可以属于多个分类（如：《Python编程》属于"编程"和"Python"）
- 一个分类包含多本书
- **需要中间表**：book_categories
3. **读者 ↔ 借阅记录**：一对多
- 一个读者可以有多条借阅记录
- 一条借阅记录只属于一个读者
4. **图书 ↔ 借阅记录**：一对多
- 一本书可以有多条借阅记录（被不同人借过）
- 一条借阅记录只针对一本书
#### 第四步：画出 ER 图
```
┌─────────┐
│ 图书 │
└─────────┘
│ id │
│ title │
│ author │
│ isbn │
└─────────┘
│
│ 1:N
│
┌─────────┐ ┌─────────┐
│ 借阅记录│────│ 读者 │
└─────────┘ └─────────┘
│ book_id │ │ id │
│ reader_id│ │ name │
│ borrowed_at│ │ phone │
└─────────┘ └─────────┘
│
│ N:M
│
┌─────────┐
│ 分类 │
└─────────┘
│ id │
│ name │
└─────────┘
```
#### 第五步：设计表结构（SQL）
```sql
-- 图书表
CREATE TABLE books (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(200) NOT NULL,
author VARCHAR(100) NOT NULL,
isbn VARCHAR(20) UNIQUE NOT NULL, -- ISBN 唯一
publisher VARCHAR(100),
publish_year INT,
stock INT DEFAULT 1, -- 库存数量
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- 读者表
CREATE TABLE readers (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(50) NOT NULL,
phone VARCHAR(20) UNIQUE NOT NULL, -- 电话唯一
email VARCHAR(100) UNIQUE,
registered_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- 借阅记录表
CREATE TABLE borrows (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
book_id BIGINT NOT NULL,
reader_id BIGINT NOT NULL,
borrowed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
due_date TIMESTAMP NOT NULL, -- 应还日期
returned_at TIMESTAMP NULL, -- 实还日期（NULL 表示未还）
status VARCHAR(20) DEFAULT 'borrowed', -- borrowed: 借阅中, returned: 已归还, overdue: 逾期
FOREIGN KEY (book_id) REFERENCES books(id),
FOREIGN KEY (reader_id) REFERENCES readers(id)
);
-- 分类表
CREATE TABLE categories (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(50) NOT NULL,
description TEXT
);
-- 图书-分类关联表（多对多）
CREATE TABLE book_categories (
book_id BIGINT NOT NULL,
category_id BIGINT NOT NULL,
PRIMARY KEY (book_id, category_id), -- 联合主键
FOREIGN KEY (book_id) REFERENCES books(id),
FOREIGN KEY (category_id) REFERENCES categories(id)
);
-- 创建索引（提升查询性能）
CREATE INDEX idx_borrows_reader_id ON borrows(reader_id);
CREATE INDEX idx_borrows_book_id ON borrows(book_id);
CREATE INDEX idx_borrows_status ON borrows(status);
CREATE INDEX idx_book_categories_category_id ON book_categories(category_id);
```
#### 第六步：应用范式（检查和优化）
**检查 1NF**：
- ✅ 所有字段都是原子的（没有字段包含多个值）
- ✅ 没有重复组
**检查 2NF**：
- ✅ 没有复合主键的情况（除了 book_categories 的联合主键）
- ✅ 所有非主键字段完全依赖于主键
**检查 3NF**：
- ✅ 没有传递依赖
- 例如：借阅记录中的 `status` 不会因为 `reader_id` 的变化而变化
**优化**：
- 考虑是否需要冗余字段？
- 例如：在 `borrows` 表中冗余 `book_title` 和 `reader_name`，避免查询时 JOIN
- **决策**：不冗余，因为查询频率不高，保持数据一致性更重要
#### 第七步：设计查询（验证设计）
**查询 1：查询读者当前借阅的所有图书**
```sql
SELECT
b.title,
b.author,
bor.borrowed_at,
bor.due_date,
bor.status
FROM borrows bor
JOIN books b ON bor.book_id = b.id
WHERE bor.reader_id = 1
AND bor.status = 'borrowed'; -- 只查未还的
```
**查询 2：查询某本书的所有借阅历史**
```sql
SELECT
r.name,
bor.borrowed_at,
bor.returned_at,
bor.status
FROM borrows bor
JOIN readers r ON bor.reader_id = r.id
WHERE bor.book_id = 1
ORDER BY bor.borrowed_at DESC;
```
**查询 3：查询逾期未还的图书**
```sql
SELECT
r.name as reader_name,
r.phone as reader_phone,
b.title as book_title,
bor.due_date
FROM borrows bor
JOIN readers r ON bor.reader_id = r.id
JOIN books b ON bor.book_id = b.id
WHERE bor.status = 'borrowed'
AND bor.due_date < NOW(); -- 应还日期早于当前时间
```
**查询 4：查询某个分类的所有图书**
```sql
SELECT b.*
FROM books b
JOIN book_categories bc ON b.id = bc.book_id
JOIN categories c ON bc.category_id = c.id
WHERE c.name = '编程';
```
#### 第八步：迭代优化（根据实际情况调整）
**问题发现**：
- 每次查询"读者借阅的图书"都需要 JOIN 3 张表（borrows、books、readers）
- 如果数据量大，查询可能慢
**优化方案 1：添加冗余字段（反范式化）**
```sql
-- 在 borrows 表添加冗余字段
ALTER TABLE borrows ADD COLUMN book_title VARCHAR(200);
ALTER TABLE borrows ADD COLUMN reader_name VARCHAR(50);
-- 修改插入逻辑
INSERT INTO borrows (book_id, reader_id, book_title, reader_name, ...)
VALUES (1, 2, (SELECT title FROM books WHERE id = 1),
(SELECT name FROM readers WHERE id = 2), ...);
-- 现在查询可以简化
SELECT book_title, borrowed_at, due_date, status
FROM borrows
WHERE reader_id = 1 AND status = 'borrowed'; -- 无需 JOIN
```
**代价**：
- 存储空间增加（每次借阅都存储书名和读者名）
- 更新复杂（修改书名时需要同步更新所有借阅记录）
**优化方案 2：添加缓存**
- 把热门读者的借阅记录缓存到 Redis
- 定期刷新缓存
**优化方案 3：添加视图**
- 创建视图简化查询
```sql
CREATE VIEW reader_borrows AS
SELECT
bor.id,
r.name as reader_name,
b.title as book_title,
bor.borrowed_at,
bor.due_date,
bor.status
FROM borrows bor
JOIN readers r ON bor.reader_id = r.id
JOIN books b ON bor.book_id = b.id;
-- 查询时直接用视图
SELECT * FROM reader_borrows WHERE reader_name = '张三';
```
::: tip 💡 数据模型设计是个迭代过程
1. **第一步**：先设计一个满足 3NF 的规范模型
2. **第二步**：根据实际查询需求，考虑反范式化
3. **第三步**：通过性能测试，找出瓶颈
4. **第四步**：优化（添加索引、缓存、冗余字段）
5. **第五步**：重复 2-4 步
**不要一开始就过度优化**！先保证正确性，再优化性能。
:::
### 8.1 数据模型设计流程总结
| 阶段 | 目标 | 产出 | 工具 |
|:---|:---|:---|:---|
| **需求分析** | 识别实体和关系 | 实体清单、关系描述 | 文档、脑图 |
| **概念设计** | 画出 ER 图 | ER 图 | draw.io、Workbench |
| **逻辑设计** | 设计表结构 | 表结构 SQL | 文本编辑器 |
| **范式检查** | 消除冗余 | 符合 3NF 的表 | 检查清单 |
| **物理设计** | 索引、分区 | 建表 SQL + 索引 | 数据库工具 |
| **性能优化** | 反范式化 | 冗余字段、缓存 | 慢查询日志 |
3. **数据归档**：历史数据迁移到归档表
---
## 9. 用 AI 辅助设计数据模型
AI 可以帮你快速生成符合规范的数据模型。关键在于提供清晰的业务描述。
### 9.1 提示词模板
```
你是一位资深的数据库架构师，精通关系型数据库设计。请帮我设计数据模型。
## 业务背景
[描述你的业务场景，例如：电商系统、博客平台、任务管理系统]
## 核心实体
[列出主要的业务对象，例如：
- 用户：注册、登录、个人信息
- 订单：下单、支付、发货
- 商品：分类、库存、价格]
## 关系说明
[描述实体之间的关系，例如：
- 一个用户可以有多个订单
- 一个订单包含多个商品
- 商品属于分类，多级分类]
## 设计要求
1. 遵循 3NF 范式
2. 明确标注主键（PK）和外键（FK）
3. 说明表之间的一对一、一对多、多对多关系
4. 考虑反范式化策略（如果需要）
5. 提供完整的建表 SQL（MySQL 语法）
## 输出格式
请按以下格式输出：
### 表结构
- 表名：说明
- 字段定义
### 关系图
用文字描述表之间的关系
### 索引建议
列出需要建立的索引
### 反范式化建议
说明哪些字段需要冗余，为什么
```
### 9.2 实战示例：博客系统
**输入提示词**：
```
你是一位资深的数据库架构师。请帮我设计一个博客系统的数据模型。
## 业务背景
一个多用户博客平台，用户可以发布文章、评论、点赞。
## 核心实体
- 用户：昵称、邮箱、密码
- 文章：标题、内容、发布时间
- 评论：评论内容、评论时间
- 标签：文章可以打多个标签
## 关系说明
- 一个用户可以发表多篇文章
- 一篇文章可以有多个评论
- 一篇文章可以有多个标签
- 一个用户可以点赞多篇文章
## 设计要求
1. 遵循 3NF 范式
2. 标注 PK 和 FK
3. 说明关系类型
4. 提供建表 SQL
```
**AI 输出示例**：
```sql
-- 用户表
CREATE TABLE users (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
nickname VARCHAR(50) NOT NULL,
email VARCHAR(100) UNIQUE NOT NULL,
password_hash VARCHAR(255) NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- 文章表
CREATE TABLE posts (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
user_id BIGINT NOT NULL,
title VARCHAR(200) NOT NULL,
content TEXT NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);
-- 评论表
CREATE TABLE comments (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
post_id BIGINT NOT NULL,
user_id BIGINT NOT NULL,
content TEXT NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (post_id) REFERENCES posts(id) ON DELETE CASCADE,
FOREIGN KEY (user_id) REFERENCES users(id)
);
-- 标签表
CREATE TABLE tags (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(50) UNIQUE NOT NULL
);
-- 文章-标签关联表
CREATE TABLE post_tags (
post_id BIGINT NOT NULL,
tag_id BIGINT NOT NULL,
PRIMARY KEY (post_id, tag_id),
FOREIGN KEY (post_id) REFERENCES posts(id) ON DELETE CASCADE,
FOREIGN KEY (tag_id) REFERENCES tags(id)
);
-- 点赞表
CREATE TABLE likes (
user_id BIGINT NOT NULL,
post_id BIGINT NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (user_id, post_id),
FOREIGN KEY (user_id) REFERENCES users(id),
FOREIGN KEY (post_id) REFERENCES posts(id) ON DELETE CASCADE
);
-- 索引建议
CREATE INDEX idx_posts_user_id ON posts(user_id);
CREATE INDEX idx_posts_created_at ON posts(created_at DESC);
CREATE INDEX idx_comments_post_id ON comments(post_id);
CREATE INDEX idx_post_tags_tag_id ON post_tags(tag_id);
```
### 9.3 AI 辅助设计的注意事项
| 注意点 | 说明 |
| :--- | :--- |
| **提供完整上下文** | 业务场景、数据量级、查询模式都要说明 |
| **明确关系类型** | 一对一、一对多、多对多要说清楚 |
| **要求解释原因** | 让 AI 说明为什么这样设计 |
| **检查约束条件** | 主键、外键、唯一索引是否合理 |
| **考虑扩展性** | 询问未来可能的扩展场景 |
| **人工审核** | AI 生成的内容需要人工检查是否符合业务需求 |
::: tip 💡 追问技巧
- "请说明这个设计遵循了哪些范式"
- "如果数据量达到千万级，如何优化"
- "哪些字段可以考虑反范式化"
- "请补充索引设计的理由"
:::
---
## 名词速查表
| 名词 | 英文 | 解释 |
| :--- | :--- | :--- |
| **数据模型** | Data Model | 对现实世界的抽象，描述数据如何存储、组织和关联 |
| **ER 图** | Entity-Relationship Diagram | 用图形化方式描述实体关系的工具 |
| **主键** | Primary Key | 唯一标识表中每条记录的字段 |
| **外键** | Foreign Key | 关联另一张表主键的字段 |
| **范式** | Normalization | 数据库设计的规范，消除数据冗余 |
| **反范式化** | Denormalization | 有意增加冗余，换取查询性能提升 |
| **一对一** | One-to-One | A 表一条记录对应 B 表一条记录 |
| **一对多** | One-to-Many | A 表一条记录对应 B 表多条记录 |
| **多对多** | Many-to-Many | A 表多条记录对应 B 表多条记录 |
| **中间表** | Junction Table | 实现多对多关系的关联表 |
| **冗余** | Redundancy | 数据重复存储 |
| **传递依赖** | Transitive Dependency | A → B → C，C 传递依赖 A |
| **部分依赖** | Partial Dependency | 非主键字段只依赖复合主键的一部分 |
| **原子性** | Atomicity | 字段不可再分的最小数据单元 |
| **宽表** | Wide Table | 字段数量特别多的表 |
| **索引** | Index | 加速查询的数据结构 |
| **约束** | Constraint | 保证数据完整性的规则（如 NOT NULL、UNIQUE） |