什么时候你的 AI 构建应用真正需要一个正式数据库(以及什么时候不需要)

数据库到底是做什么的?

数据库唯一的工作,就是确保两个人在同时使用同一个应用时,不会不小心覆盖或破坏彼此的工作——速度、结构和复杂查询,都只是解决这一个核心问题时顺带得到的好处。

你用 AI 搭建了自己的应用。它能用,能把数据存进文件或表格里。一切看起来都还不错。

然后,以下两种情况之一发生了:

每次有人用你的应用,它都会变得更慢一点。
两个用户同时使用时,出问题了。

这两种故障在出现之前都不明显,等你发现时往往为时已晚。它们本质上都是”伪装过的数据库问题”。

如果你现在还在用文件或表格存数据,那大概率你还没有真正的数据库。这没关系。但你应该了解,哪些迹象说明你快需要一个了。

什么时候用文件代替数据库是可以的?

只要你是应用的唯一使用者,而且数据改动不频繁,用文件就完全没问题——这就是判断的全部标准。

自由职业者的作品集网站?文件完全够用。个人记账小工具?文件没问题。一个只有你自己在用的业余项目?别把它搞复杂了。

真正说明”文件够用”的迹象:

同一时间只有一个人在用这个应用(或者别人用的时候你是离线的)。
你很少更新数据(一天一次、一周一次,或者一个月一次)。
就算丢失最近 30 秒的操作也无所谓(让你的搭建工具重试一遍就行)。
数据文件小到可以直接用邮件发送(小于 10 MB)。

如果这四条都成立,那就继续用文件吧。真的,别多想。简单本身就是一种优势,而不是局限。

为什么我用 AI 搭建的应用会越来越慢?

应用变慢,是因为它保存数据的文件在不断变大,而每次要改动任何内容时,你的搭建工具都要把整个文件加载进内存——这个代价一开始几乎感觉不到,但随着文件变大,会越来越难受。

你会先从一种”感觉”上注意到它。应用感觉比以前慢了。点一下按钮要多等一秒。搜索明显变慢了。你又没改代码,为什么会变慢?背后的规律是这样的:

应用加载完整数据文件(100 行,很快)。
用户新增一条记录(现在是 101 行)。
应用重新读取整个文件来做二次校验(依然很快)。
到了 2,000 条记录时,读取文件要花 2 秒。
到了 10,000 条记录时,要花 20 秒。

这不是指数级增长,但大概到 5,000 条记录时会开始明显,到 20,000 条时就会让人难以忍受。

第一步该做的(在你添加数据库之前): 让你的搭建工具改成按需加载数据。只加载你要展示的那几条记录,或者只加载你要显示的那几列。很多应用只要在加载方式上聪明一点,就能继续用文件撑下去。

什么时候该迁移到数据库: 数据量超过 50,000 条记录,或者即便优化了加载方式,变慢的问题依然存在。

为什么两个人同时使用我的应用时,数据丢失了?

这是因为两个人可以同时编辑同一个文件,而应用完全不知情——谁后保存,谁的版本就生效,先保存的那个人的改动会悄无声息地消失。这叫”写入冲突”,是经典的数据丢失 bug。

两个人在各自的屏幕上都能看到自己的改动。他们都点了”保存”。如果出现以下情况,说明你正遇到这个问题:

用户时不时反馈数据丢失了(尤其是多人同时在用应用的时候)。
用户反馈说,别人的改动莫名其妙被”撤销”了。
两个用户编辑同一条记录,结果其中一个人的编辑内容消失了。
你会收到类似这样的留言:“我昨天明明加了这条记录,现在怎么没了。”

这不是应用本身的错,而是文件这种存储方式的固有局限。没有数据库,这个问题基本无解。

什么时候该迁移到数据库: 只要开始有两个人同时使用这个应用,哪怕目前还没出过问题,也该迁移了。

为什么用文件做不了复杂搜索?

因为用文件的话,你的搭建工具得手动一步步加载和筛选每个相关的数据集,而不能直接问一个问题就得到一个答案——数据库只需一条查询语句,就能在几毫秒内完成同样的工作。

假设你想查”所有加州客户中,未付款且最近一周未被联系过的发票”。用文件的话,你的搭建工具得这样做:

加载所有发票。
筛选出未付款 = true 的记录。
加载所有客户信息,按 ID 匹配。
筛选出所在州 = “CA” 的记录。
加载所有联系记录,按客户 ID 匹配。
筛选出日期在一周之前的记录。

用数据库的话,你只需写一条查询语句,几毫秒内就能搞定这一切。

什么时候该迁移到数据库: 当你的搭建工具告诉你”要回答这个问题,得写一段专门的自定义代码”时。或者你发现,应用为了给你展示筛选后的数据,要做大量额外工作时。

需要数据库时,该怎么跟我的搭建工具说?

直接说清楚出了什么问题,然后请它给出方案——比如可以这样说:“应用现在[变慢了/出现过数据丢失/需要支持更复杂的搜索]。我觉得我们该加一个数据库了。这算是个多大的改动?”

对小型应用来说,大多数搭建工具能在 1–2 天内把应用从文件迁移到数据库;规模更大的应用可能要几天时间。整个过程大致是:

应用整体保持不变(用户基本感觉不到明显变化)。
接入数据库后端(对代码的其他部分来说,看起来还是跟文件一样,但底层已经是数据库了)。
做足够充分的测试(因为迁移数据是件很敏感的操作)。
让新旧两套系统并行运行一周,直到你确信没问题为止。

搭建工具可能会问你:

“我们该用 PostgreSQL、MySQL,还是别的?”
- 你可以回答: “你最顺手的就用哪个。我不懂它们的区别,但我信你的判断。”
“这个改动大概要 3 天。值得做吗?”
- 你可以回答: “反正早晚都要迁移,数据越多以后迁移越麻烦,不如早点做。”
“旧数据要不要一起迁移过去?”
- 你可以回答: “要,除非数据量不到 100 条,那样的话直接从头开始也没问题。“

我自己需要懂数据库吗?

不需要——你不需要弄懂什么是数据库、不需要学 SQL,也不需要纠结 PostgreSQL 和 MySQL 该选哪个。你只需要告诉你的搭建工具一句话:“要让两个人能同时使用这个应用,而且互相不覆盖对方的工作。”

就这么简单。数据库该选哪种,交给你的搭建工具来决定就行。像 SQLite 这样简单的方案(适合个人或团队使用、并发用户数少于 10 人的应用),或者 PostgreSQL(适合规模更大的场景),都能胜任这个任务。

我怎么知道自己的应用需不需要数据库?

对照下面这四条,看看自己符合哪几条——只要勾选了两条或以上,就说明现在该加数据库了。

变慢: 应用比 3 个月前明显慢了。数据文件超过 20 MB,或记录数超过 10,000 条。
数据丢失: 有人的改动消失了,或者多个用户都反馈过编辑内容丢失。
复杂查询: 你想问类似”按 Y 筛选后给我看 X”这样的问题,而搭建工具告诉你”用文件很难做到”。
多用户: 不止一个人在同时使用这个应用(哪怕只是偶尔同时使用)。

如果你勾选了两条或以上,说明你的应用已经该上数据库了。

如果你一条都没勾选,说明用文件就挺好,继续用吧。简单是有价值的。

如果你只勾选了一条,可以问问你的搭建工具:“这个速度,再撑 6 个月没问题吗?”如果回答是肯定的,那就再等等。如果不行,那就现在开始迁移。