数据持久化：何时文件已经不够
复习
- 构建与依赖：把代码变成可交付产物
- 文件：把数据长期保存到磁盘
- 契约、错误与异常：明确地处理失败
TL;DR
- 数据要长期保存，就需要持久化
- 简单场景下，用文件就够了
- 但当需要并发、按条件查询、一致性时，文件会很吃力
- 数据库作为外部服务，负责保存、查询和更新数据
正文
程序运行时的数据大多在内存里，一关就没了。要让它长久保存，就得持久化（persistence）——把数据写到磁盘上。最开始，我们会想到文件。
文件：够用的起点
很多场景下，文件是完全够用的：
- 保存配置、日志
- 存一份程序自己读写、格式自定的数据
- 数据量不大、访问简单
这时候，直接读写文件简单直接，不必引入更复杂的东西。能用简单办法解决，就别急着上复杂工具。
什么时候文件不够了
但随着需求变复杂，文件会越来越吃力：
- 并发：多个人（或多个程序）同时读写同一个文件，很容易互相覆盖、写坏
- 查询：想要“找出所有满足某条件的记录”，文件只能一遍遍读取、自己过滤
- 一致性：一次修改牵涉多处，中途出错就可能留下“改了一半”的坏数据
- 规模与效率：数据一大，全文件扫描慢得难以接受
这些要求加在一起，用文件硬撑，会把自己写成一个难以维护、bug 频出的“土数据库”。
数据库作为外部服务
于是，人们把“保存、查询、更新数据”这件事，交给专门的软件——数据库（database）。
这里我们只把它当成一个外部服务来理解：程序通过它保存数据、按条件查询数据、更新数据。至于它内部怎么组织文件、怎么保证并发和一致性，暂时当作黑箱——那是另一个庞大的领域。
关键是认识到：当“保存数据”的需求，升级成“可靠、并发、可查询地管理数据”时，专业的事就该交给专业的工具。 这和整部教程里“加一层、用现成的抽象”是同一个思路。
思考题 1
什么情况下，用文件保存数据就够了？
思考题 2
当需要“按条件查询”和“多人同时修改”时，为什么文件会很吃力？
小结
知识点
- 持久化把数据长期保存到磁盘
- 简单场景用文件足够
- 并发、查询、一致性与规模会让文件吃力
- 数据库作为外部服务负责保存、查询与更新
参考资料
- Wikipedia(zh)：持久化：把数据长期保存下来
- Wikipedia(zh)：数据库：以结构化管理数据的系统
思考题答案（仅供参考）
思考题 1
当数据量不大、访问方式简单、基本不存在多人并发修改时，用文件保存就足够，例如配置、日志或格式自定的本地数据。这时引入数据库反而增加复杂度。
思考题 2
因为文件缺乏对并发的控制，多人同时读写容易互相覆盖；而按条件查询只能一遍遍读取并自行过滤，数据一大就非常慢。此外，牵涉多处的修改也难以保证“要么全成、要么全不做”，容易留下不一致的数据。
协议
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
封面图
设计师 | 南国微雪