数据库复习：SQL、规范化、NoSQL 与常见数据库类型

数据库设计的核心是根据数据关系、查询模式和扩展需求选择合适模型。

MySQL 与 PostgreSQL

MySQL 常用于 Web 应用、读写简单、生态成熟的业务场景。

PostgreSQL 功能更丰富，支持复杂查询、JSON、扩展能力和更严格的数据一致性。

简单理解：

MySQL：轻量、常见、上手快
PostgreSQL：强大、严谨、适合复杂业务

SQL 基础

SELECT * FROM users WHERE age > 18;
 
INSERT INTO users (name, age) VALUES ('Alice', 25);
 
UPDATE users SET age = 26 WHERE name = 'Alice';
 
DELETE FROM users WHERE id = 1;

数据库规范化

规范化是为了减少数据冗余和更新异常。

第一范式：字段不可再分。

第二范式：非主属性完全依赖主键。

第三范式：非主属性不依赖其他非主属性。

实际项目中也会为了性能进行适度反规范化。

NoSQL 类型

文档数据库：如 MongoDB，适合 JSON 文档。

键值数据库：如 Redis，适合缓存和快速查询。

列族数据库：适合大规模分布式写入。

图数据库：适合关系网络、推荐系统和路径分析。

选择思路

如果数据关系清晰、事务重要，优先关系型数据库。如果数据结构灵活、扩展性要求高，可以考虑 NoSQL。

延伸理解

复习这篇时，不要只记住名词，要把重点放在 关系模型、规范化、索引、事务、NoSQL 类型和数据库选型。这类知识如果只停留在定义层面，很容易在面试或项目中答得很散。更好的理解方式是把它放进一个具体场景：谁在调用它，输入从哪里来，失败后谁负责恢复，数据或状态会不会被重复处理。

数据库选型要从查询模式、写入模式、一致性要求、数据规模和团队运维能力出发。
关系数据库适合强约束和复杂查询，NoSQL 更适合特定访问模式下的扩展性。
索引、事务、隔离级别、备份恢复和迁移策略通常比单纯语法更影响系统稳定性。

在真实项目中，可以把它当成一个判断框架：先确认输入、约束、失败场景和可观测性，再决定具体工具或写法。如果一个方案看起来很简单，要继续追问它在规模扩大、权限变化、异常恢复和团队协作下是否仍然成立。

实践检查清单

明确这个知识点在系统中的位置：是开发时约束、运行时能力、基础设施能力，还是协作流程。
写出一个最小可运行例子，并补一个失败例子；只会写 happy path 说明理解还不够稳。
记录常见误用：例如边界条件、权限假设、性能假设、同步/异步差异或环境差异。
把概念和项目经历关联起来：如果面试被追问，可以用自己的项目说明为什么这样选。
最后用一句话总结取舍：它牺牲了什么，换来了什么。

自测问题

这个主题解决的核心问题是什么？
如果不用当前方案，还有哪些替代方案？代价是什么？
最容易出错的边界条件在哪里？
如何在代码、测试或监控中验证它真的可靠？

项目化应用场景

可以把这类知识放到订单、用户或内容系统中理解：关系数据库适合保存强一致、强约束的数据，例如用户、订单和支付记录；NoSQL 适合访问模式明确、扩展压力大的数据，例如缓存、会话、时间线或键值配置。数据库设计不是先选工具，而是先写出主要查询：按什么字段查、是否分页、是否需要事务、写入频率多高、历史数据如何归档。

常见误区：

没有查询模式就先建表或集合。
滥用 JSON 字段导致查询和约束失控。
以为加索引一定更快，却忽略写入成本。

目录