来源：https://github.com/datawhalechina/vibe-vibe

本节目标：理解数据存储方式的演进路径，知道什么时候该用数据库。

第一阶段：CSV / Excel — 能用，但很快就不够

Excel 和 CSV 是大多数人接触数据管理的起点。CSV（Comma-Separated Values，逗号分隔值）本质上就是纯文本版的 Excel，每行一条记录，逗号隔开字段。你用记事本就能打开它，任何编程语言都能轻松读写：

电影名,导演,评分,标签,年份
流浪地球,郭帆,7.9,科幻,2019
哪吒之魔童降世,饺子,8.4,动画,2019
霸王别姬,陈凯歌,9.6,剧情,1993

小明遇到的问题：

问题一：一部电影多个标签怎么办？

《流浪地球》既是"科幻"又是"灾难"还是"国产"。在 CSV 里，标签列只能写成 科幻/灾难/国产，用斜杠拼在一起。想查"所有科幻片"？得用字符串匹配，又慢又容易出错——"科幻片"和"科幻"匹配不上，"硬科幻"也匹配不上。

这个问题的本质是：CSV 的每个格子只能放一个值。当一个字段需要存多个值时（多个标签、多个演员），CSV 就力不从心了。你只能把多个值硬塞进一个格子里，然后在查询时用各种字符串技巧去拆分——这既脆弱又低效。

问题二：数据不一致

小明有时候写"郭帆"，有时候写"郭帆导演"，有时候手滑写成"郭凡"。200 条数据里，同一个导演可能有三四种写法。Excel 不会提醒你，错了就是错了。

等到小明想统计"郭帆导演的作品平均分"时，他发现只统计到了一部——因为另外两部的导演名字写错了。这种错误在数据量小的时候不明显，数据一多就成了噩梦。你甚至不知道有多少数据是错的，因为没有任何机制帮你检查。

问题三：关联数据放不下

小明想加一个功能：记录每部电影的演员表。一部电影有十几个演员，一个演员演过几十部电影。这种"多对多"关系，一张 Excel 表根本放不下。

硬塞的话，要么一行变得超级长（把所有演员名字用逗号拼在一起），要么得建好几张表然后手动对照——"这个演员 ID 对应哪个人来着？"每次查询都要在多张表之间来回跳，纯靠人脑关联，效率极低还容易出错。

问题四：多人协作是灾难

小明想让朋友一起维护这个片单。两个人同时编辑同一个 Excel 文件？要么覆盖对方的修改，要么产生冲突文件。Google Sheets 虽然能多人同时编辑，但它本质上还是电子表格，前面三个问题一个都没解决。

CSV/Excel 适合什么？一次性的数据分析、简单的配置清单、几十行的小数据。一旦数据量上去、关系变复杂、需要多人协作，就该换方案了。

第三阶段：数据库 — 专业的事交给专业的工具

小明在 CSV 和 JSON 上踩了一圈坑之后，终于决定用数据库。他选了 PostgreSQL（原因在 6.0 节已经介绍过），把数据拆成了几张表：

• movies 表：存电影基本信息（片名、年份、评分、简介）
• directors 表：存导演信息（姓名、国籍）
• actors 表：存演员信息（姓名、国籍）
• movie_actors 表：记录哪个演员演了哪部电影（中间表，解决多对多关系）
• tags 表：存标签（科幻、动作、文艺……）
• movie_tags 表：记录哪部电影有哪些标签（又一个中间表）

你可能会问：为什么要拆成这么多张表？直接一张大表不行吗？

不行。一张大表意味着大量的数据冗余。比如"吴京"这个演员出现在 20 部电影里，如果用一张表，"吴京"的名字、国籍等信息就要重复存 20 遍。改一下他的信息，就要改 20 个地方，漏改一个就是数据不一致。拆成独立的 actors 表后，"吴京"只存一条记录，所有电影通过 ID 引用它，改一处全部生效。

这就是关系型数据库的核心思想：通过拆表和关联，消除数据冗余，保证数据一致性。

现在，之前的所有问题都解决了：

小明用一条 SQL 就能查到"吴京演过的所有 8 分以上电影"：

SELECT m.title, m.rating
FROM movies m
JOIN movie_actors ma ON m.id = ma.movie_id
JOIN actors a ON ma.actor_id = a.id
WHERE a.name = '吴京' AND m.rating >= 8.0

你不需要看懂这条 SQL 的语法——AI 会帮你写。但你需要理解它在做什么：从三张表（电影、中间表、演员）里，通过 ID 关联，找出符合条件的数据。这就是关系型数据库的威力：数据分散存储，查询时动态关联。

这条查询在几百万条数据里也能在毫秒内返回结果——因为数据库会自动使用索引优化查询路径。而同样的操作，用 JSON 文件可能需要几秒甚至几十秒。