数据库课程笔记：从 SQL 到规范化

这份笔记把几次数据库课程整理放回同一张目录里。以前记数据库时，我很容易把概念写成一长串名词：关系、范式、索引、视图、事务，每个词都认识，连在一起却不知道要解决什么问题。重新整理以后，我更愿意从一条数据怎样被描述、查询、约束和恢复来理解它。

从数据模型开始

数据库不是“把数据放进表里”这么简单。现实对象先被抽象成实体、属性和联系，再落到关系模型中的表、列和行。主键回答“怎样区分一条记录”，外键回答“记录之间怎样关联”，域和约束则限制一列可以接受什么值。

如果一张订单表里同时放顾客姓名、商品名称和商品价格，修改商品名称时就可能只改到其中几行。问题出在模型把几个不同事实混在了一起。拆成顾客、商品和订单明细后，表之间的关系更清楚，修改也更容易保持一致。

SQL 的重要之处不在于语句长，而在于它描述“想要哪一组结果”，而不是逐行告诉数据库怎样循环。SELECT、WHERE、GROUP BY 和 HAVING 组合起来，可以把筛选、分组和聚合表达成一条可检查的查询。

SQL

SELECT category_id, COUNT(*) AS total
FROM posts
WHERE is_published = true
GROUP BY category_id
HAVING COUNT(*) > 3;

WHERE 在分组前过滤行，HAVING 在分组后过滤结果。这个顺序看起来是语法细节，实际会影响结果和性能。多表查询也一样，先写清楚连接键和预期行数，再决定是否需要外连接或子查询。

更新和删除更需要谨慎。执行前先把条件改成 SELECT 检查命中范围，重要操作放进事务，并在日志或备份里留下回滚依据。没有 WHERE 的 UPDATE 属于不可逆风险，不能把它当成“快速修复”。

规范化的目标是减少重复和更新异常。第一范式要求字段保持原子性，第二、第三范式继续处理部分依赖和传递依赖。课程里的范式推导很整齐，真实系统却常常在一致性、查询路径和写入成本之间取舍。

我现在会先识别事实的所有者，再看是否真的存在重复。为了报表读得更快而做适度反规范化时，也要说明由哪一层负责更新，以及怎样校验冗余值没有漂移。把“为了性能”写成理由还不够，应该有测量和回归条件。

索引不是给每一列都加上的装饰。它适合经常出现在过滤、连接和排序中的字段，但会占空间，也会增加写入成本。查看执行计划、比较有无索引的查询时间，比凭感觉添加索引更可靠。

视图可以把一组复杂查询封装成稳定的读取接口，简化使用并隐藏部分字段。但视图不是缓存，也不会自动解决慢查询；如果底层表变化频繁，仍然要关注执行计划和权限边界。

数据库安全不只是“设置一个密码”。最小权限、参数化查询、审计日志、敏感字段保护和备份恢复共同决定数据能否被可靠使用。应用层校验不能替代数据库约束，数据库约束也不能替代权限设计。

恢复演练比备份文件更能说明系统状态。一次完整演练要记录数据库版本、备份位置、恢复时间和恢复后的行数校验。只有能从备份回到可工作的状态，数据安全才不是一句口号。

课程知识最后会落到很具体的动作：先画出数据关系，再写查询；先检查命中范围，再做更新；先看执行计划，再加索引；先验证恢复，再宣称有备份。数据库因此不再是一组需要背下来的章节，而是一种让事实、约束和变化保持可解释的方式。