第 2 章 数据库设计原则与实践

第 2 章 · 数据库设计原则与实践

章节摘要：第 1 章回答了"单个字段怎么定"，本章回答"整张表怎么长出来"。设计评审的第二次交锋聚焦三件事：流程有没有走对（先需求后建模，而不是先建表后补需求）、实体关系有没有理清（ER 模型是业务与技术之间的翻译器）、范式与反范式的天平往哪边倾。这一章把"建表评审会"从字段过堂升级到结构论证。

学习目标

阅读完本章，你应当能够：

1. 说清设计流程四个阶段的产出物，识别"跳过概念设计直接写 DDL"这种危险动作；
2. 独立画出三实体以上的 ER 图，正确标注一对一、一对多、多对多及基数约束；
3. 判断一个表结构违反了第几范式，并给出拆解方案；
4. 在读多写少或写多读少的场景下，论证反范式化的引入范围与同步代价；
5. 为一张新表制定命名规范方案，包括前缀、分隔符、缩写、注释四要素；
6. 用"变更会扩散到哪里"这句话，在评审会上预判设计缺陷的长期成本。

核心概念速览

设计的本质是翻译：把业务语言（客户、订单、库存）翻译成数据结构（表、列、外键）。流程保证翻译不走样，ER 模型是翻译的草稿纸，范式是译文的语法校对，反范式是针对性能场景的有意破格。

金句：范式不是教条，是让每一份事实只有一个存放地点的纪律；反范式不是放纵，是明知要付同步代价时的深思熟虑。

子章节导航

2.1 数据库设计流程：从需求到 DDL 的四阶段各自产出什么、评审会在每个阶段的角色。重点讲一个反例——某团队跳过概念设计直接建表，半年后字段含义没人说得清，最终被迫推倒重来。附设计评审泳道图。

2.2 实体关系模型：ER 图的三要素与三种基数关系，用电商"客户—订单—商品"三角做完整演练。多对多关系如何落地成中间表、中间表为什么常常长出业务字段，是本节的核心洞察。

2.3 范式与反范式：1NF 到 3NF 的判定口诀与拆表演示；什么时候该故意"违规"——反范式化的适用边界、冗余字段的同步策略，以及一张权衡对照表。

子章节之间的逻辑关系

三节是同一条流水线的三道工序：流程划定"在哪一步干什么"，ER 模型是概念设计的具体工具，范式校对发生在逻辑设计阶段，反范式则是物理设计阶段的定向调整。跳过任何一环，债务都会在评审后的某个深夜找上门。

+------------------+   产出实体草图   +------------------+
| 2.1 设计流程     | --------------> | 2.2 ER 模型      |
|  四阶段与产出物  |                  |  三要素与基数    |
+--------+---------+                  +--------+---------+
         |                                     |
   控制推进节奏                          概念结构定稿
         v                                     v
+------------------+   违规要付代价   +------------------+
| 评审会：卡点放行 | <-------------- | 2.3 范式与反范式 |
+------------------+   定向冗余补偿  +------------------+
​

前置知识与后续延伸

本章直接调用第 1 章的类型与约束知识——拆表之后每张新表的字段定义，都要过 1.3 节那套标准。反过来，本章产出的表结构是第 3 章 SQL 演练的对象，也是第 4 章索引设计的地基：索引建立在"哪些列被查询"的预判上，而这个预判正来自设计阶段的访问模式分析。范式之争还会在第 5 章、第 6 章反复回响——每次讨论 JOIN 数量、每张宽表膨胀，根子都在这里。

设计不是画完图就结束的动作，而是贯穿系统生命周期持续谈判的过程。评审会永远开不完，但每一轮都要比上一轮更接近业务的真相。