📄 一句话概括
名字是设计的门面：命名规则（统一风格、见名知义）管「怎么起」；同义词（用户/客户口径）与同形同音异义词管「起名前先对齐语义」——名字起歪，后面每个 JOIN 都要猜谜。
📝 本节和前面几节的关系
类型定了（5-14），最后一道工序是起名。这是逻辑→物理下楼前的收尾，5-16 起的书评网站实战将直接使用本节的规则。
一、命名规则四条
- 见名知义：
users.nickname✅；t1.c2❌ - 风格统一：蛇形小写
user_id（业界主流）；选一种全库到底 - 单复数有约定：表名常用复数（
users）或统一单数（user）——选一种，别混 - 保留字回避：
order、group是 SQL 关键字，表名列名别撞（要撞就加反引号，但能不撞就不撞）
二、同义词：同一个东西，多种叫法
业务里「顾客／客户／用户」混着叫；系统里必须选定一个（比如 customer），文档里登记「本系统中『用户』『会员』一律指 customer」。选定哪个不重要，全库唯一才重要。
三、同形(同音)异义词：一个词，两种理解
- 「部门」：按组织架构的部门？还是按业务线？（两个口径都能自圆其说）
- 「单价」：含税？不含税？（同音不同义，最阴险）
药方：起名时把歧义词拆开——tax_included_price / tax_excluded_price，一词一义，绝不共用。
四、动手 Demo：给书评网站起名
| 实体 | 表名 | 主键 | 说明 |
|---|---|---|---|
| 用户 | users |
user_id |
别叫 member/user_info 混用 |
| 书 | books |
isbn |
ISBN 天然唯一 |
| 书评 | reviews |
review_id |
「书评」统一译 review，全文档对齐 |
口径登记：本系统「书评＝review（含评分+正文）」，不另设「短评」；「评分＝score 0~10」。
五、30 秒实验
审这三列名：姓名、mingzi、user_name_cn——哪个能用？命名规则三条齐查：见名知义 ✅、风格统一（中文/拼音/英文混着叫 ❌）、口径登记了吗？（_cn 说明将来还有英文名列，先留好约定 ✅）。
六、常见误区
- 「名字随便起，反正能查」：半年后的你、接手的同事都要靠名字读代码；命名是最便宜的文档
- 「同义词不用管，都能听懂」：人能听懂，SQL 不参与语境——
WHERE 用户='VIP'里这个『用户』到底是 customer 还是 member？
自测三问
1. 命名规则四条？（见名知义/风格统一/单复数约定/避保留字） 2. 同义词问题怎么治？（全库选定唯一术语并登记） 3. 同形同音异义词怎么治？（拆词——含税价不含税价分开命名）- ☐ 下一节（5-16 提取需求-书评网站表格设计的示例1-完成后的示意图）
相关笔记
- 数值类型、字符串类型、日期类型-确定分配给列的设置 —— 上一节：类型配好了
- 提取需求-书评网站表格设计的示例1-完成后的示意图 —— 下一节：实战开工
- 🗄️ 数据库基础 · 索引 —— 全课路线图