企业是怎么开始跟数据打交道的？从纸质台账到关系型数据库，讲清「数据库」这个所有后续故事的起点：为什么它从不记错账，以及为什么它天生只擅长处理一笔。
在讲 Snowflake、Databricks、向量数据库这些名词之前，我们必须回到最原始的问题：一家企业，是怎么开始跟数据打交道的？这一篇从纸质台账讲到关系型数据库，解释一个多数人日用而不知的东西——数据库到底是什么、它解决了什么问题、以及为什么全世界的程序员都在用同一种语言跟它说话。
本篇要回答的问题
1. 数据库到底是个什么东西？它比 Excel 强在哪？
2. 「关系型数据库」这个词为什么听起来玄，实际却是最符合人类直觉的发明之一？
3. 什么叫 OLTP（业务数据库）？为什么说它是「超市收银台」？
4. 数据为什么会「堆积」，堆积之后的第一缕麻烦是什么？
想象 1985 年的一家百货商店。每一笔销售记录在一张纸质单据上：商品、数量、单价、金额、售货员。晚上关门后，会计把这些单据汇成日报表，月底再汇成月报表。进货同样有账：库存台账记着每个商品的进出。
这套体系运转了人类商业几百年，它有两个与生俱来的特点。第一，「记」和「查」是分开的：写账很快（往本子上记一笔），但查账很慢（想知道「王师傅这个月卖了多少」要翻遍整个月的单据）。第二，改账是大事件：记错了一笔，不能直接擦掉，而是用红笔划掉重写，旁边签名——因为账本是一条证据链，任何无痕的修改都会让整本账的可信度崩塌。
这两个特点——写入快、查询慢；改动必须可追溯——几乎是刻在商业数据骨子里的基因。你后面会看到，五十年后所有的数据技术，本质上都在处理这两个问题的现代版本。
1980 年代末，个人计算机进入企业。第一反应非常自然：把账本变成电子表格。每笔销售存成一个文件，库存一个文件，客户名单一个文件。这比纸质账本快得多，也好查得多——按 Ctrl+F 就能找到「王师傅」。
但生意一大，电子文件立刻暴露出纸质账本没有的新问题，而且一个比一个致命：
文件时代的四大灾难
灾难一：两个人同时改一个文件。销售部小李更新了客户电话，财务部老王同时也在编辑同一个文件保存——老王保存的瞬间，小李的修改被覆盖没了。文件系统对此毫无办法。
灾难二：同一个事实存了好几份。客户的地址在销售文件里存一份，在发货文件里存一份，在售后文件里又存一份。客户搬家了，改了销售那份，另外两份忘了改——从此公司里流传着三个不同版本的这个客户地址，没人知道哪个是真的。
灾难三：改格式牵一发动全身。销售文件里「手机号」字段是 11 位，现在要加国际区号，改成 15 位——所有读这个文件的程序（财务系统、报表程序）全都要跟着改代码，改漏一个就崩溃。
灾难四：断电了怎么办。写到一半断电，这个文件可能只有半条记录——账本记一半，比不记还糟糕。
这四个灾难的本质是同一句话：当多个人、多个程序同时共享同一份数据时，需要一个公正的中间人来管理。这个中间人，就是数据库。
中间人的设计蓝图，来自 1970 年 IBM 研究员埃德加·科德（Edgar Codd）的一篇论文。他提出的思想朴实到令人意外：把所有数据组织成一张一张的二维表格——每一行是一条记录，每一列是一个属性，表与表之间用公共字段相互引用。
你可能觉得这不是废话吗？Excel 不就是表格？但科德的表格和 Excel 的表格有本质区别，恰恰对应文件时代的四大灾难：
| 文件时代的灾难 | 关系型数据库的解法 |
|---|---|
| 两人同时改一个文件 | 数据库内置「锁」机制：小李改这条记录时自动加锁，老王排队——每个人看到的永远是完整一致的数据 |
| 同一事实存多份 | 「客户地址」只存在一张「客户表」里，其他表只存客户编号（外键）——地址只此一份，改一处全局生效 |
| 改格式牵一发动全身 | 数据（表）与程序分离——程序通过统一的语言（SQL）向数据库要数据，不关心数据怎么存；改表结构不影响程序逻辑 |
| 断电写一半 | 事务日志：每笔操作先写日志再改数据，断电重启后按日志恢复——要么整笔完成，要么当作没发生 |
这四条解法合在一起，就是行话里的 ACID：原子性（一笔操作要么全成要么没发生）、一致性（任何时刻账目自洽）、隔离性（多人同时操作互不干扰）、持久性（确认成功就绝不丢）。翻译成人话就一句：它从不记错账。
科德的另一个深远贡献是 SQL（Structured Query Language，结构化查询语言）。你向数据库要数据，说的是这样一句话：
SELECT 姓名, SUM(金额) FROM 销售记录 WHERE 售货员='王师傅' AND 月份='1月' GROUP BY 姓名;
翻译成人话：「从销售记录表里，把王师傅 1 月的销售额加总告诉我。」注意这句话的妙处：你只描述你要什么，不描述怎么找——翻哪些页、用什么索引、内存怎么调度，全是数据库自己的事。这门语言后来成了全行业的通用语：Oracle、DB2、SQL Server、MySQL、PostgreSQL，乃至五十年后的 Snowflake 和 Databricks，全都说 SQL。一门语言统治一个行业五十年，这让数据库成为人类商业世界里标准化的最大成功案例之一。
有了关系型数据库，企业数字化开始铺开：销售系统、库存系统、财务系统、人事系统……每个系统背后都是一个数据库。这一类数据库的工作模式，行话叫 OLTP（Online Transaction Processing，联机事务处理）——名字唬人，实质就是「处理一笔一笔的业务」：收银台扫一笔码记一笔账，客服改一个地址，仓库出入一件货。
OLTP 的特征决定了它的设计取向：单次处理的数据量很小（一笔订单几十个字段），但要求极快、极高并发、绝对可靠——超市收银台一次处理 3 秒可以接受，卡死 30 秒就是事故；双十一零点每一秒都是几千笔下单，一秒都不能乱。为这些目标优化的数据库（Oracle、DB2、MySQL、PostgreSQL）在过去的五十年里支撑了全世界的商业运转。
这里有一个对后文极其重要的观察：OLTP 数据库是「活在当下」的。它记的是此刻发生的业务，为了保持速度，它往往只保留最近的热数据（几年前的历史订单会被归档移走）；它的表格结构为「快速写一笔」设计，而不为「扫描全部历史找规律」设计。换句话说——数据的「账本」和「档案室」天生应该是两个房间。但绝大多数企业起步时并不知道这一点，他们把档案室和收银台设在了同一个房间。麻烦，就是从这里开始的。
1990 年代到 2000 年代，数据库市场是 Oracle 的天下。它的商业模式在那个年代无懈可击：软件按 CPU 数量收授权费，大型企业一套系统授权费加服务费动辄数百万美元，还要每年付 22% 的维护费。全球的银行、电信、政府都跑在 Oracle 上——它稳定、强大，而且你已经离不开它（所有业务系统都建在它上面，换数据库等于心脏移植）。
这种「稳」与「锁」并存的格局，催生了两个历史性的变量。第一个是开源：MySQL（1995）和 PostgreSQL（1996 年以今天形态发布）以免费授权、功能够用的姿态，吃下了互联网时代的大部分新增市场——你今天用的每一个 App，背后的业务数据库大概率是这两者之一。第二个变量来自 Google：2000 年代初，Google 面对的「数据」已经不是 OLTP 能理解的东西了——全网网页的索引、全球用户的搜索日志，规模以 TB、PB 计，且不需要「事务」这种东西（网页索引记错了刷新一遍就好，不存在「账目对不上」）。Google 为此发明了一套全新的技术路线，并在 2003–2006 年间发表了三篇论文（俗称「三驾马车」）。
这三篇论文的影响极其深远——它们直接催生了 Hadoop，开启了「大数据」这个概念，也埋下了数据湖的种子。但那是第二篇和第三篇的内容。
在本篇收尾之前，请记住这个时间线上微妙的错位：当 OLTP 世界已经百花齐放时，「分析」这个需求还挤在业务数据库的角落里艰难生长。分析师想要一张「过去五年每个城市每个品类的销售趋势」报表，只能在业务库上跑一个长查询——查询跑起来，整张表被锁住，收银台跟着卡顿。于是企业的妥协方案是：让分析师在夜里跑报表（业务低峰期），或者把数据导出到 Excel 里自己算。
数据还在堆积，而且是以指数速度堆积。收银台房间里的档案已经堆到了天花板——一个专门给「分析」盖的房间，呼之欲出。
本篇历史事实（科德 1970 论文、ACID、Oracle 商业模式、MySQL/PostgreSQL 发布时间、Google 三驾马车论文时间）为数据库行业公认史实，可在 Wikipedia「Relational database」「SQL」词条及 Oracle 公司公开资料交叉验证。类比（收银台/财务分析部、账本红线规则）为本文原创科普表达。
系列下一篇 · 《数据仓库：分析的觉醒》——为什么企业宁可把数据搬一次家，也要给分析单独盖一个房间？Teradata 一体机凭什么卖到百万美元级？以及「数据孤岛」这个所有故事的起源。