第31天 #100DaysOfCode — SQL + NoSQL 基础
发布: (2026年3月5日 GMT+8 08:09)
6 分钟阅读
原文: Dev.to
看起来您只提供了来源链接,而没有贴出需要翻译的正文内容。请把要翻译的文本(除代码块、URL 之外)粘贴在这里,我会按照要求保留源链接并将其余部分翻译成简体中文。
Source: …
结构化方式(表格与行)
这就是所谓的 关系型数据库 —— 一种将数据组织成表格的方式,其中:
- 表(Table) → 代表一个实体(例如,用户、订单)
- 行(Row) → 该表中的一条记录/条目(例如,一个用户)
- 列(Column) → 一个属性/字段(例如,姓名、电子邮件、年龄)
- 单元格(Cell) → 行与列交叉处的实际值
它看起来就像电子表格:
| id | name | |
|---|---|---|
| 1 | John | john@gmail.com |
| 2 | Saad | saad@gmail.com |
🔑 关键概念
- 模式(Schema) – 所有表的整体结构/蓝图
- 主键(Primary Key) – 每行的唯一标识符
- 外键(Foreign Key) – 将一个表链接到另一个表的列
- 关系(Relationship) – 表之间的连接方式
🟦 SQL 基本语法
创建表
CREATE TABLE users (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100) NOT NULL,
email VARCHAR(255) UNIQUE,
age INT
);
插入行
INSERT INTO users (name, email, age)
VALUES ('Alice', 'alice@email.com', 28);
读取数据
SELECT name, email
FROM users
WHERE age > 25
ORDER BY name ASC
LIMIT 10;
更新行
UPDATE users
SET age = 29
WHERE email = 'alice@email.com';
删除行
DELETE FROM users
WHERE age `, `<`, `IN`, `LIKE`.*
更新文档
db.users.updateOne(
{ email: "alice@email.com" },
{ $set: { age: 29 } }
);
删除文档
db.users.deleteMany({ age: { $lt: 18 } });
连接集合(使用 $lookup 的聚合)
db.orders.aggregate([
{
$lookup: {
from: "users",
localField: "user_id",
foreignField: "_id",
as: "user"
}
},
{ $unwind: "$user" }
]);
聚合管道示例
db.users.aggregate([
{ $match: { age: { $gt: 20 } } },
{ $group: { _id: "$age", count: { $sum: 1 } } },
{ $sort: { count: -1 } }
]);
🔵 NoSQL / 文档数据库的使用场景
- 内容管理与博客平台
- 社交媒体信息流与用户资料
- 实时聊天与消息传递
- 产品目录
- 移动和游戏应用
- 用户活动与行为分析
- 物联网与传感器数据
- 推荐引擎
- 物流与配送跟踪
- 快速原型开发与创业公司
🔵 SQL vs 🟠 NoSQL:何时使用哪种?
为什么选择 SQL
| 场景 | 原因 |
|---|---|
| 结构化、关系型数据 | 表之间具有明确的关系(用户 → 订单 → 产品) |
| 数据完整性至关重要 | ACID 事务、外键、约束 |
| 复杂查询 | JOIN、聚合、报表、分析 |
| 模式稳定 | 数据结构不经常变化 |
为什么选择 NoSQL
| 场景 | 原因 |
|---|---|
| 高度可变或不断演进的模式 | 无模式集合允许每个文档的字段不同 |
| 大规模水平扩展 | 内置分片和分布式架构 |
| 针对简单查询的快速读写 | 去规范化数据消除昂贵的 JOIN |
| 非结构化或半结构化数据 | 类 JSON 文档自然映射到许多现代数据格式 |
两种范式各有优势;正确的选择取决于您应用的具体需求。
金融/事务系统
银行、ERP、电子商务后端
何时使用 NoSQL
| 场景 | 原因 |
|---|---|
| 灵活/不断演进的模式 | 字段在每条记录中不同;模式经常变化 |
| 大规模与高速 | 横向扩展到多台服务器 |
| 非结构化 / 半结构化数据 | JSON 文档、日志、传感器数据 |
| 高写入吞吐量 | 每秒数百万事件(Cassandra、DynamoDB) |
| 层次或图形数据 | 嵌套文档(MongoDB)、关系(Neo4j) |
| 缓存 | 像 Redis 这样的键值存储 |
🧭 快速决策指南
Is the data relational with a stable schema? → SQL
Need ACID compliance (finance, healthcare)? → SQL
Unknown/flexible data structure? → NoSQL (Document)
Massive scale, simple lookups? → NoSQL (Key‑Value)
Graph relationships (social networks)? → NoSQL (Graph)
Time‑series or IoT data? → NoSQL (Wide‑Column)
✅ 结论
第 31 天让我清晰地看到 SQL 与 NoSQL 的区别——不仅在语法上,更在哲学层面。
- SQL 注重结构、规则和一致性。
- NoSQL 强调灵活性、速度和可扩展性。
了解何时选择它们是后端开发者的核心技能,这次对比帮助我巩固了这一认识。
明天我将基于此基础继续我的 #100DaysOfCode 之旅。
感谢阅读,欢迎分享你的想法!