SQL vs NoSQL 数据库示例

以下示例展示了同一产品为何可向任一侧倾斜——分析需要 SQL，CMS 常适合 NoSQL，实时应用可能两者都用，多数成熟系统最后变成多语言持久化。

真实案例

使用场景: 构建 BI 或分析产品的团队

跨 users/orders/products 的复杂多表 JOIN

对历史数据的聚合查询（SUM、GROUP BY）

强制 schema 以保证数据质量

窗口函数、CTE 和 SQL 生态工具

ACID 在报表必须与事务对账时很重要

这样组织的原因: 分析是 SQL 的主场——图表左侧（规范化表 + JOIN）让跨实体的临时查询成为可能。NoSQL 能模拟一部分，但要付出去规范化的复杂度。

使用场景: 构建 CMS、商品目录或动态信息流的团队

每条记录是自包含的文档

字段按条目类型变化——SQL 里要写 30 个可空列

读多的访问模式：一次取一个文档

添加新字段无需迁移

按条目 id 分片，水平扩展

这样组织的原因: 内容/目录访问是层级化且读多的——图表右侧（一次取出整个文档）很合适，因为多数查询是「给我这条」而非「跨条目 JOIN」。

使用场景: 构建聊天、游戏或社交功能的团队

用户档案与好友关系 → SQL（关系型、事务型）

聊天消息和动态流 → NoSQL（高写吞吐、层级化）

在线状态和会话 → 内存 KV（Redis）

没有单一数据库适配全部访问模式

按功能选存储

这样组织的原因: 实时应用通常两者都用——图表抓住二元选择，但生产现实是不同功能落在线的两侧，各自由其访问模式决定。

使用场景: 在生产同时运营两类技术的成熟团队

Postgres 负责 OLTP 和真相来源

MongoDB / DynamoDB 负责内容和事件日志

Redis 负责缓存和会话状态

Elasticsearch 负责全文搜索

每个存储在自己擅长的访问模式上胜出

这样组织的原因: 多语言持久化是多数成熟系统最终的样子——SQL-vs-NoSQL 图表成为起点框架，而生产架构在它之上叠加，按访问模式选引擎。

回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。