数据库冗余与第三范式
部门表
| ID | NAME | Detail |
|---|---|---|
| 1 | 开发部 | 介绍 |
| 2 | 产品部 | product |
| 3 | 销售部 | 卖出去 |
员工表（存在冗余，不符合第三范式）
| ID | NAME | Intro | DepartmentName | DepartDetail |
|---|---|---|---|---|
| 1 | 张飞 | 冲动 | 开发部 | 介绍 |
| 2 | 关羽 | 衷心 | 产品部 | product |
员工表（规范化设计）
| ID | NAME | Intro | DepartmentID |
|---|---|---|---|
| 1 | 张飞 | 冲动 | 1 |
| 2 | 关羽 | 衷心 | 2 |
有冗余，不符合第三范式。
第三范式有些时候也不一定都要遵守，有些时候可以部分不遵守，有冗余可以提升系统性能。
比如新闻表和评论表，每一条新闻都有多条评论，这是一对多的关系。假设我要知道新闻的最新评论以及新闻的评论数量。
你可能会这样做：根据新闻 ID 去读取评论表，可能会读出很多评论记录，然后再获取这些评论中时间最后的那条。
另一种做法：新闻表里面有一个字段，用来记录最新评论的文本和 ID。