我的小屋

一、SQL 在干什么：建表、改表与增删改#

1
CREATE TABLE S (
2
    `S#` VARCHAR(10) PRIMARY KEY,
3
    SNAME VARCHAR(50) NOT NULL,
4
    AGE INT CHECK (AGE BETWEEN 0 AND 120),
5
    SEX CHAR(1) CHECK (SEX IN ('M','F','男','女'))
6
);
7

8
CREATE TABLE SC (
9
    `S#` VARCHAR(10),
10
    `C#` VARCHAR(10),
11
    GRADE DECIMAL(5,2),
12
    PRIMARY KEY (`S#`, `C#`),
13
    FOREIGN KEY (`S#`) REFERENCES S(`S#`),
14
    FOREIGN KEY (`C#`) REFERENCES C(`C#`),
15
    CHECK (GRADE IS NULL OR GRADE BETWEEN 0 AND 100)
16
);

1
SELECT `C#`, COUNT(*) AS 人数
2
FROM SC
3
GROUP BY `C#`
4
HAVING COUNT(*) > 15
5
ORDER BY 人数 DESC, `C#` ASC;

1
SELECT s.SNAME, sc.GRADE
2
FROM S s
3
JOIN SC sc ON s.`S#` = sc.`S#`
4
WHERE sc.`C#` = 'C1'
5
ORDER BY sc.GRADE DESC;

1
SELECT c.`C#`
2
FROM C c
3
WHERE NOT EXISTS (
4
    SELECT 1
5
    FROM S s
6
    JOIN SC sc ON s.`S#` = sc.`S#`
7
    WHERE s.SNAME = 'WANG'
8
      AND sc.`C#` = c.`C#`
9
);

1
SELECT c.`C#`, c.CNAME,
2
       AVG(sc.GRADE) AS 平均成绩,
3
       MAX(sc.GRADE) AS 最高成绩
4
FROM C c
5
JOIN SC sc ON c.`C#` = sc.`C#`
6
WHERE c.TEACHER = '李文'
7
GROUP BY c.`C#`, c.CNAME;

二、关系代数与 SQL 的对应（心里有个映射）#

比如「WANG 不学的课号」用代数可写成：$\pi_{C\#}(C) - \pi_{C\#}(\sigma_{SNAME='WANG'}(S) \bowtie SC)$。写 SQL 时不一定要先写代数，但差集类问题先想「全集减去已选集合」会少绕弯。

三、数据库设计：从 E-R 到关系模式#

设计题的核心步骤我习惯固定成三步：

1. 找实体：各自有哪些属性，谁是主标识（主键候选）。
2. 找联系：1<1>、1、M，联系有没有自己的属性（如借阅日期、成绩）。
3. 转关系模式：实体各成一张表；1 把「一」方主键放进「多」方作外键；M 单独建联系表，主键常是两端主键的组合。

图书借阅例子（简化）：

• 出版社 —(1)— 书籍：出版社名可放进书籍表作外键。
• 借书人 —(M)— 书籍：拆成 借阅（书号，借书证号，借书日期，还书日期），两端都是外键。

运动会里「一个裁判组只负责一个比赛项目」往往是 1<1>：可以把裁判组编号放进比赛项目表，并加 UNIQUE 保证一个裁判组只对应一个项目。

商品进销存里供应商—商品、商店—客户—商品可能出现 三元联系，最终也会落成带多个外键的联系表，并想清楚候选码（例如是否要把「销售日期」放进主键，避免同一天多笔交易冲突）。

四、范式：为什么要拆表#

一张「大而全」的表容易出现四类问题：

1. 冗余：同一学生姓名、系别因多门课重复多行。
2. 插入异常：还没选课的学生，若主键是（学号+课程号），连基本信息都难插。
3. 删除异常：删掉某人选的最后一门课，可能连人带课信息一起丢。
4. 更新异常：改名、改系名要改很多行，容易不一致。

判断范式时我会先写 函数依赖 FD 和 候选码：

• 选课大表 R（学号，姓名，年龄，系别，课程号，课程名，成绩）
  • 学号 → 姓名，年龄，系别
  • 课程号 → 课程名
  • （学号，课程号）→ 成绩
  • 候选码：（学号，课程号）
  • 存在部分依赖（学号、课程号各自决定非主属性）→ 至少要做 3 张表：学生、课程、选课。

学生表带系名（学号→系号，系号→系名）会出现传递依赖，属于 2NF 但不到 3NF，应拆出 系（系号，系名） 和 学生（学号，姓名，年龄，性别，系号）。

库存（仓库号，地点，设备号，设备名，库存数量） 典型拆法：

• 仓库（仓库号，地点）
• 设备（设备号，设备名）
• 库存（仓库号，设备号，库存数量）

五、视图、存储过程与触发器（会用即可）#

视图适合统计展示，例如按读者统计借阅册数：

1
CREATE OR REPLACE VIEW v_bnum (`读者号`, `借阅数量`) AS
2
SELECT r.`读者号`, COUNT(b.`图书号`)
3
FROM `读者` r
4
LEFT JOIN `借阅` b ON r.`读者号` = b.`读者号`
5
GROUP BY r.`读者号`;

触发器常用来维护一致性：学号在 S 表变更时同步 SC；删学生时级联删成绩；订单插入后扣减商品库存。写之前要弄清 BEFORE / AFTER 以及 NEW / OLD 的含义。

存储过程 / 函数适合封装「按订单号算总金额」「按学号返回性别」这类重复逻辑；注意 DELIMITER 和 IN / OUT 参数。

六、工程里还会碰到什么#

课上综合题常把几块拼在一起，我自己记成四句话：

• 性能：给 WHERE、JOIN、ORDER BY、GROUP BY 高频列建合适索引；用 EXPLAIN 看计划；少 SELECT *。
• 安全：最小权限、GRANT/REVOKE、角色；敏感字段加密；视图隐藏列；审计日志。
• 并发：事务 ACID；隔离级别与脏读、不可重复读、幻读；选课、库存用事务 + 行锁 / 条件更新防超卖。
• 备份恢复：全量 + 增量/binlog；主从提高读能力；定期做恢复演练。

选课高峰、二手平台大促这类场景，本质都是：索引扛查询、事务扛一致性、备份扛故障。

写在最后#

对我来说，数据库这门课适合按 SQL 熟练 → 多表与聚合 → E-R 设计 → 范式分解 → 视图/过程/触发器 → 性能与安全 这条线推进。教学库 S/C/SC、图书借阅、供应商零件 SP、集团人事 EMP/WORKS/COMP 这几类模型反复出现，把「不学的课」「没供应的零件」「没任职的职工」写对，大部分查询题就有套路了。

如果你也在学数据库，欢迎一起交流；文中有错漏也请在评论区指正。