编辑模式 · 点击文字即可修改 · Ctrl+S 导出 再次按 E 或点击左上角退出
模块 6.3 · 数据库前传

数据都存在哪儿？

把数据存起来，给项目加上记忆

没有记忆，谁在意？

记忆，对谁有价值？

🙋 用户
查一句、拿到结果，人就走了——多数时候，并不在意历史。
🛠 运营者
·每天有多少人来查？
·大家都在查什么？
·模型放到真实句子上，到底准不准？
先有需求，才有数据库

存储信息，是几千年的需求

🪢
结绳
🪨
泥板
📒
账本
🗄️
档案柜
🗃️
数据库
最新一环
一体两面

存，是为了取

📄 一堆草稿纸
也是"存"了——可要取某一条，得翻半天，甚至翻不到。
存 ✓  ·  取 ✗
🗂 分类档案柜
贴好标签、分门别类——要取哪条，一下就找到。
存 ✓  ·  取 ✓
存在哪儿

数据，都能存在哪儿？

⚡
内存
速度快 · 不持久
本节
📄
文件
持久 · 简单
🗃️
数据库
存得好 · 取得快
☁️
云 / 对象存储
大文件 · 图片视频
text原文 用户查的那句话
score分数 情感分 0~1
label结论 偏积极 / 偏消极 / 中性
pinyin拼音 带声调
created_at时间 这条是什么时候查的
1
今天心情不错,0.88,偏积极,jīn tiān…,2026-08-16T07:30
我喜欢,真的喜欢"我喜欢, 真的喜欢",0.96,偏积极,wǒ xǐ huān…,2026-08-16T07:31

 

1234
{
  "text": "他说你好""他说"你好"""他说\"你好\"",
  "score": 0.96,
  "label": "偏积极"
}

原文里的引号，撞上了 JSON 的引号 ✗库自动加了转义符 \"——问题解决 ✓

12
📍
广州 · 客户端
下午三点？15:00
UTC+8
📍
旧金山 · 客户端
下午三点？00:00
UTC−7
🖥️
服务器
下午三点 ❓07:00 UTC

规矩：存的时候一律用 UTC（带 +00:00），显示时再按用户所在地转本地。

1
main.py内存里的列表
records = []
  1. 今天心情不错0.88
  2. 这部电影很不错0.91
  3. 风很轻0.62
  4. 有点小失望0.28
  5. 还可以吧0.55
  6. 夜色真美0.90 · 新
]
读全部（5 条）
整份写回（6 条）
🗂️ history.json硬盘文件
[
  1. 今天心情不错0.88
  2. 这部电影很不错0.91
  3. 风很轻0.62
  4. 有点小失望0.28
  5. 还可以吧0.55
  6. 夜色真美0.90
]

整份覆盖 · 重写全部 6 条

123
程序 A内存
records = []
  1. 今天心情不错0.88
  2. ⋯ 中间 98 条省略 ⋯
  3. 还可以吧0.55
  4. 今晚夜色真美0.90
]
读全部
100 条
A 写回
101 条
🗂️ history.json硬盘文件
[
  1. 今天心情不错0.88
  2. 这部电影很不错0.91
  3. 风很轻0.62
  4. 有点小失望0.28
  5. ⋯ 中间 95 条省略 ⋯
  6. 还可以吧0.55
  7. 今晚夜色真美0.90 这车动力很足0.87
]
程序 B内存
records = []
  1. 今天心情不错0.88
  2. ⋯ 中间 98 条省略 ⋯
  3. 还可以吧0.55
  4. 这车动力很足0.87
]
读全部
100 条
B 写回
覆盖

B 后写、直接覆盖——先写进去的「今晚夜色真美」凭空丢了

脏写
12345
main.py写入中
正在整份写回
101 条…▍
✕ 写到一半
进程崩了 / 断电
整份写回中… 写一半 · 中断
🗂️ history.json硬盘文件
[
  { "text": "今天心情不错", "score": 0.88 },
  { "text": "这部电影很不错", "score": 0.91 },
  { "text": "风很轻", "score": 0.6▍ ✕崩
✕ 少了收尾的 ] —— 整份 JSON 都读不出

所有数据挤在一个文件里，写坏一个括号 → 整份都读不出

一坏全坏
1
/api/history读数据
1全部读进内存10000 条
2倒序 reverse()新的排前
3切片 [:10]只剩 10 条
读全部
10000 条
🗂️ history.json硬盘文件
[
  1. 今天心情不错0.88
  2. 这部电影很不错0.91
  3. ⋯ 共 10000 条 ⋯
  4. 还可以吧0.55
]

只想要 10 条，却把 10000 条 全搬进内存——数据一大，内存吃不消

123
问题清单

文件存储的弊端

效率
①只要 10 条，也得读全部
②存一条，也要整个重写
并发 + 健壮
③多人同时读写：脏写 / 脏读
④写一半崩了：一坏全坏
谁来收拾

事务：多人并发读写的安全机制

A 写
B 写
C 读
事务 transaction
排队协调，谁也不覆盖谁、谁也读不到半截
🗃️
数据
始终完整
这历史是"谁的"？

能把大家的输入，公开列在页面上吗？

✗ 公开展示所有人的输入
·用户写的内容属于 UGC
·个人主体备案，不能做 UGC 业务
·法人主体展示 UGC，还需许可证
这不是技术问题，是合规问题。
✓ 只给用户看他自己的
这个功能合规没问题。但技术上有个前提——
得先认得出用户，给每条记录带上"是谁存的"标记。
👤
人
💻
浏览器
📱
换个设备
🖥️
服务端
会话 session
认证 authentication

服务端认得这个浏览器——刷新之后，还是它 服务端认得这个人——换电脑、换浏览器也认得

12
下一节

下一节，
数据库

今天数出的四处痛，正是它存在的理由——把这四笔账，一个一个报销。