唐纳德·钱伯林与 SQL：让数据库查询变得简单

为什么唐纳德·钱伯林和 SQL 仍然重要

唐纳德·D·钱伯林不是家喻户晓的名字，但他的工作悄然决定了大多数软件团队处理数据的方式。作为IBM的研究员，钱伯林共同创造了SQL（最初拼作SEQUEL），这门语言使得日常开发者——甚至非专业人员——也能对大型数据库提出查询。

在SQL出现之前，从存储的数据中获取答案通常需要编写定制程序或使用功能强但笨拙的工具。钱伯林推动了另一种想法：与其一步步告诉电脑如何查找数据，不如以接近普通英语的形式描述你想要的结果。

一个看似简单但影响巨大的想法

SQL的核心是一种令人惊讶地以人为本的方式：

• 你命名想要的数据（SELECT）
• 你说明数据所在的位置（FROM）
• 你描述筛选条件（WHERE）

现在听来显而易见，但那是一次重大转变。它把“查询数据库”从专家任务变成了可以被教授、共享、审查和改进的事情——就像软件开发的其他部分一样。

本文要做（和不会做）的事

这是一个关于SQL如何诞生以及它为何广泛传播的实用历史。

你不需要高级数学、形式逻辑或深厚的数据库理论来跟上本文节奏。我们将聚焦于SQL解决的现实问题、为何其设计容易上手，以及它如何成为软件行业的默认技能——从后端工程到分析、产品和运维。

如果你曾筛选列表、对结果分组或连接两组信息，那你已经在用SQL使之主流的思维方式在思考。钱伯林的持久贡献是把这种思路转化为人们实际能使用的语言。

在SQL出现之前，数据工作是什么样子

在SQL之前，大多数组织并不“查询数据库”。他们处理的是存储在文件中的数据——通常每个应用对应一个文件，由创建它的程序管理。薪资有自己的文件、库存有自己的文件、客户记录可能分散在多个系统中。

这种基于文件的方法能工作，直到企业需要跨界的问题："哪些客户买了产品X并且还有未付发票？"要得到这样的视图，就必须把原本不为合并设计的数据拼接起来。

从共享数据到分散文件

在许多早期系统中，数据格式与应用紧密耦合。某处的一个变动——比如为客户添加电话号码字段——可能需要重写程序、转换文件和更新文档。即便“数据库系统”开始出现，很多仍然暴露低级访问方法，让人感觉像在编程而不是在提出问题。

早期数据访问为何如此困难

如果你想要信息，通常有两个选项：

• 向懂得文件结构的专家请求定制程序。
• 依赖为狭窄目的设计的固定报表（按日、周定时）。

两种选择都不利于探索。文字上的小变化——加一个日期范围、按地区分组、排除退货——可能变成新的开发任务。结果是瓶颈：有问题的人必须等待会写代码的人。

缺少的那一环：一种通用语言

组织缺少的是一种表达数据问题的共通方式——既要对机器足够精确，又要对人足够可读。业务人员以“客户”“订单”“总额”来思考，而系统则围绕文件布局和过程步骤构建。

这种差距催生了对查询语言的需求：一种能把意图翻译为操作的、可复用的一致表达方式，而不是每次都写新程序。这个需求为SQL的突破铺平了道路。

奠定舞台的关系模型思想

在SQL出现之前，数据库世界需要一种更清晰的思考数据的方式。关系模型提供了这一点：一种简单一致的框架，把信息存储在表（关系）中，由行和列组成。

更清晰的目标：一致性胜过定制接线

关系模型的核心承诺很直接：不要为每个应用构建一次性、难以维护的数据结构。相反，把数据以标准形式存储，让不同的程序无需重写数据组织就能提出不同的问题。

这次转变重要，因为它把常被缠在一起的两件事分离开来：

• 数据如何存储（具有明确定义列的表）
• 数据如何使用（可以随时变化的查询）

当这些关注点被分开后，数据更容易共享、更新更安全，也不那么依赖某个应用的特殊设计。

Edgar F. Codd 的影响——不需要英雄式叙事

Edgar F. Codd 在IBM帮助形式化了这一思想，并解释了它为何优于通过固定路径导航记录的方法。你不需要完整的学术背景来理解影响：他给了行业一个可推理、可测试和可改进的模型。

为什么它实际上需要一种新型查询语言

一旦数据以表的形式存在，下一个自然问题是：普通人如何提出他们需要的内容？不是指向存储位置，而是描述要得到的结果。

那种“描述你想要什么”的方法——选择这些列、过滤这些行、连接这些表——为一种以人为友好的查询语言铺平了道路。SQL就是为利用那种模型而构建的，把关系理论变成日常工作。

IBM System R 与寻找更好查询语言的过程

IBM System R 最初并不是商业产品——它是一个研究项目，旨在回答一个现实问题：Edgar F. Codd 的关系模型能否在真实世界、真实规模和真实业务数据下工作？

当时，许多数据库系统通过物理访问路径和逐条记录逻辑进行导航。关系数据库承诺不同的东西：把数据存储在表中，清晰地描述关系，让系统自己决定如何检索结果。但这个承诺依赖两方面协同工作：一个高效的关系引擎和一个普通开发者（甚至一些非开发者）也能使用的查询语言。

System R 试图证明的事

System R 于1970年代在IBM圣何塞研究实验室开发，目标是构建一个关系数据库管理系统原型并对关系思想进行压力测试。

同样重要的是，它探索了如今已成基础的技术——尤其是查询优化。如果用户要编写高级请求（“给我这些满足这些条件的记录”），系统需要自动地把这些请求翻译成高效操作。

钱伯林的角色与团队背景

在IBM的研究环境中工作的唐纳德·钱伯林，专注于缺失的那部分：一种对关系数据提出问题的实用语言。他与合作者（尤其是 Raymond Boyce）一起塑造了一种与人自然描述数据需求相匹配的查询语言。

这并非在真空中设计语言。System R 提供了反馈回路：如果某个语言特性无法高效实现，它就不会存活；如果某个特性能让常见任务更容易，它会获得动力。

语言需求为何不寻常

Codd 用形式数学（关系代数和关系演算）描述了关系模型。这些思想很强大，但对日常工作过于学术化。System R 需要一种语言，要求是：

• 声明式（说你想要什么，而不是如何去取）
• 足够可读以便教授和共享
• 可实现且具备良好性能

这种基于可运行原型的寻找，奠定了SEQUEL继而成为SQL的舞台。

从 SEQUEL 到 SQL：以人为友好的设计

钱伯林与同事最初把新语言命名为 SEQUEL，意为 Structured English Query Language（结构化英文查询语言）。名称暗示了核心思想：不再编写过程代码去逐步导航数据，而是以接近日常英语的形式陈述你想要的东西。

后来将名称缩短为 SQL（部分出于实用——更短、更便于打印和发音，也与商标命名有关）。但“结构化英文”的志向仍然存在。

一种读起来像请求的语言

设计目标是让数据库工作感觉像提出一个清晰请求：

• SELECT 你想要的信息
• FROM 它所在的位置
• WHERE 条件为真

这种结构给了人们一个一致的心智模型。你不必学习某个厂商的特殊导航规则；你学会了一种可读的询问模式。

一个小示例：筛选、排序、汇总

想象一个简单的业务问题："今年哪些加州客户消费最多？" SQL 允许你直接表达该意图：

SELECT customer_id, SUM(amount) AS total_spent
FROM orders
WHERE state = 'CA' AND order_date >= '2025-01-01'
GROUP BY customer_id
ORDER BY total_spent DESC;

即使你刚接触数据库，也往往能猜出这段代码的作用：

• 筛选到今年在加州的订单
• 按客户汇总消费
• 按总额倒序排列，使最大总额显示在前

这种可读性——配合明确规则——帮助SQL从IBM System R走向更广泛的软件世界。

SQL 如何把问题分解成简单部分来表达

SQL 能流行的一个原因是它让你以口语化的方式表达问题："选这些内容，从这个地方，满足这些条件。"你不必描述如何一步步找到答案；只需描述想要什么。

构建模块（用通俗语言）

SELECT = 选出你想看到的列。

FROM = 从哪个表（或数据集）获取这些事实。

WHERE = 过滤行，只保留符合条件的。

JOIN = 连接相关表（例如把 orders 的 customer_id 与 customers 表的 customer_id 匹配）。

GROUP BY = 按类别汇总，以便讨论“每位客户”、“每月”或“每个产品”的总计。

一个可以按句子阅读的小示例

SELECT customer_name, COUNT(*) AS order_count
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
WHERE orders.status = 'Shipped'
GROUP BY customer_name;

把它读作："选出每位客户的名字和订单数量，从与客户关联的订单中，只保留已发货的订单，并按客户汇总。"

保持非技术化：用问题思考，而不是标点符号

如果SQL让你感到害怕，退一步，把你的目标用一句话重述。然后把词映射到语句：

• 我想看什么？→ SELECT
• 它在哪儿？→ FROM
• 我应当排除什么？→ WHERE
• 需要匹配什么？→ JOIN
• 我想要按哪类统计？→ GROUP BY

以问题为先的习惯才是SQL“以人为友好”设计的真正内核。

为何SQL让数据库更易接近

SQL不仅引入了一种与数据对话的新方式——它降低了成为“数据库人”的门槛。在SQL之前，向数据库提问通常意味着编写过程代码、理解存储细节或向专家团队提交请求。钱伯林的工作帮助把局面翻转：你可以描述想要的结果，数据库负责决定如何检索它。

降低更多角色的门槛

SQL 最大的可访问性收益在于它足够可读，可以在分析师、开发者和产品团队之间共享。即使初学者也能理解像这样的查询意图：

SELECT product, SUM(revenue)
FROM sales
WHERE sale_date >= '2025-01-01'
GROUP BY product;

你无需了解索引结构或文件布局就能看出在问什么：给定日期范围内按产品计算的总收入。

改善协作的共享语言

由于SQL是声明式并被广泛教授，它在规划和调试时成为共同参考点。产品经理可以校验问题（“我们是否算上退货？”）。分析师可以调整定义。工程师可以优化性能或将逻辑移入应用或数据流管道。

更重要的是，SQL让“问题”本身可被审查。它可以版本控制、注释、测试和改进——像代码一样。

局限：可访问性不等于正确性

SQL使得提问更容易，但并不保证答案可靠。你仍然需要：

• 干净且建模良好的数据（重复、缺失值和不一致的ID会误导任何查询）
• 清晰的定义（什么算作“活跃用户”，适用哪个时区，收入如何确认）

SQL为自助式数据工作打开了大门，但良好结果仍依赖于良好数据和共享语义。

SQL 如何成为行业默认

SQL之所以胜出，不是因为它是唯一的查询语言，而是因为它对一个需要共享惯例的成长中行业而言非常实用。一旦团队看到SQL可以让他们在不为每个报表编写定制代码的情况下提出清晰问题，它就开始出现在更多产品、培训和职位描述中。

采用通过工具而非仅仅是数据库扩散

随着数据库厂商加入对SQL的支持，其他软件也随之受益。报表工具、商业智能仪表盘以及后来的应用框架都因拥有一种通用的数据获取和整形方式而受益。

这产生了一个正反馈循环：

• 支持SQL的数据库越多 → 基于SQL的工具越多
• 工具越多 → 学习SQL的人越多
• 学习者越多 → 公司越倾向于期望SQL技能

即便数据库内部不同，熟悉的SQL“表面”减少了切换系统或集成多个系统的成本。

可移植性：悄然的超能力

可移植性并不等于“毫无改动即可运行任何地方”。它意味着核心概念——SELECT、WHERE、JOIN、GROUP BY——在不同产品中保持可识别。为一个系统写的查询通常只需小幅调整就能在另一个系统上运行。这降低了厂商锁定并使迁移变得不那么可怕。

标准化，通俗解释

随着时间推移，SQL被标准化：一套共享的规则和定义，厂商大体上同意支持它。把它想象成语言的语法。不同地区有口音和俚语，但基本语法让你可以交流。

对个人和组织而言，这种标准化带来了巨大影响：

• 技能可以跨岗位和行业转移
• 培训材料更持久有效
• 软件团队更容易招聘

最终结果是：SQL 成为处理关系数据的默认“共同语言”。

SQL 对软件的连锁影响

SQL不只是改变人们如何查询数据——它改变了软件的构建方式。一旦存在了一种通用的数据库询问方式，整类产品就可以假设“SQL 可用”，并专注于更高层的功能。

SQL 作为默认的连接组织

你可以在业务应用（CRM、ERP、财务系统）、报表仪表盘以及用于获取和更新记录的Web服务中看到SQL的身影。即使用户从未输入过查询，许多应用也在后台生成SQL来筛选订单、计算总额或组装客户画像。

这种普及创造了一个强大模式：如果你的软件会说SQL，它就能以较少定制集成与多种数据库系统协作。

围绕通用语言建立的生态系统

共享的查询语言使得构建围绕数据库的工具成为可能：

• BI与分析工具：让非技术团队探索数据并生成图表，通常通过将点击转换为SQL来工作。
• ETL/ELT 管道：在系统间移动并转换数据，经常使用SQL进行连接、聚合和数据清洗。
• 管理与开发工具：用于监控、调优、迁移与模式变更。
• 培训与招聘：课程、认证和面试环节将SQL视为基础技能。

关键点是，这些工具并不依赖单一厂商接口——它们依赖可迁移的SQL概念。

现代类比：把SQL看作AI辅助构建的稳定“契约”

SQL在2025年仍然重要的一个原因是，它像意图与执行之间的持久契约。即便你用更高层的工具或AI构建应用，仍然需要一个明确、可测试和可审计的数据库层。

例如在 Koder.ai（一个通过聊天创建Web、后端和移动应用的vibe-coding平台），团队常常把“应用应该做什么”以清晰的关系表和SQL查询的形式落地。底层通常是用 Go 后端和 PostgreSQL，SQL仍然是连接、过滤与聚合的共享语言——而平台加速了脚手架、迭代和部署过程。

对SQL的批评与误解

SQL存在数十年，也因此积累了许多抱怨。许多批评在狭窄语境下是有道理的，但人们常常在缺乏现实场景细节的情况下重复这些说法。

“SQL太复杂”

SQL 在你看到 SELECT ... FROM ... WHERE ... 时显得简单，但随后复杂性就来了：连接、分组、窗口函数、公共表表达式、事务、权限、性能调优。这个跃迁令人沮丧。

一个有用的框架是：SQL 在核心小而在边缘大。核心思想——过滤行、选择列、组合表、聚合——很快能学会。复杂性通常出现在你要精确处理真实世界数据（缺失值、重复、时区问题、混乱的标识）或在大规模下追求性能时。

“SQL充满奇怪的边缘情况”

一些“奇怪”其实是SQL对数据诚实地表达。例如，NULL 表示“未知”，既不是0也不是空字符串，所以比较行为不同。另一个常见意外是，如果你不显式排序，同一查询在不同时间可能以不同顺序返回行——因为表不是电子表格。

这些并不是放弃SQL的理由；它们提醒我们，数据库更倾向于为正确性和清晰性优化，而不是隐式假设。

“SQL不一致，因为每个数据库都有自己的版本”

这种批评混淆了两件事：

• SQL 标准：定义了语言基础的正式规范。
• SQL 方言：具体产品（PostgreSQL、MySQL、SQL Server、Oracle、SQLite 等）里的实际用法。

厂商会添加特性以竞争并服务用户——额外函数、不同的日期处理、专有扩展、专门索引、过程化语言。这就是为什么某个系统能运行的查询在另一个系统可能需要小改动。

实用建议：先学核心，再选“主用”数据库

先掌握可移植基础：SELECT、WHERE、JOIN、GROUP BY、HAVING、ORDER BY，以及基本的 INSERT/UPDATE/DELETE。一旦这些变自然，选择你最可能使用的数据库并学习它的特性与怪癖。

如果你自学，保留一张个人备忘单记录遇到的差异会很有帮助。这样“方言令人恼火”就会变成“我知道该查什么”，这才是日常工作的现实技能。

今天初学SQL的友好路径

学习SQL不是死记语法，而是养成一种习惯：先提出清晰问题，然后把它翻译成查询。

一个真正管用的简单学习路径

从一张小表开始（想想 customers 或 orders），先练习读取数据再去做其它事情。

1. 小表查询：用 WHERE 和 ORDER BY 进行过滤和排序。练习只选择需要的列。
2. 连接（Joins）：当单表查询熟练后，用 JOIN 连接两表（例如 orders + customers）。
3. 聚合：学习 GROUP BY 来回答“多少？”和“多少值？”的问题——计数、求和、平均、按月总计。

这个进阶顺序反映了SQL的设计：把问题分成部分来表达，然后让数据库决定最优执行方式。

从一开始就养成安全习惯

如果你在共享数据库上练习，或还新到会误点东西，遵循这些规则保护自己：

• 先只用 SELECT。 把它当作“只读模式”。
• 探索时限制结果：加上 LIMIT 50（或你使用数据库的等价语法），避免拉取数百万行。
• 避免破坏性命令（DELETE、UPDATE、DROP），直到你完全理解 WHERE 条件并有安全沙箱。
• 在编辑数据前，先预览：运行对应 SELECT 来验证将被更改的行。

用真实问题练习

好的SQL练习看起来像真实工作：

• “本年按月的销售额”
• “按收入排名的前10位客户”
• “哪些产品经常被一起购买？”

选一个问题，写查询，然后检查结果是否合乎常识。这样的反馈循环能让SQL变得直观。

如果你在同时构建真实项目学习SQL，把模式、查询和应用代码放在一起会有帮助。例如在 Koder.ai 上快速原型一个以 PostgreSQL 为后端的小应用，你可以快速迭代表和查询、快照变更，并在准备好时导出源码——同时不会丢失实际的SQL逻辑视角。

唐纳德·钱伯林的遗产与SQL的持久生命力

钱伯林的持久贡献不仅在于发明语法——而在于他搭建了一座人和数据之间的可读桥梁。SQL让人们能够描述想要什么（加州客户、本月销售、库存低的产品），而不必逐步写出计算机如何去获取。这个转变把数据库查询从专家手艺变成了团队可以讨论、审查和改进的共享语言。

一种超越其初始时代的语言

SQL之所以经久不衰，是因为它处在一个有用的中间地带：既足够表达复杂问题，又足够结构化以便被优化和标准化。即使新型数据工具层出不穷——仪表盘、无代码界面、AI助手——SQL仍是可靠的底层层面。许多现代系统仍把点击、筛选和提示翻译成类似SQL的操作，因为数据库可以验证、保护并高效运行这些操作。

为什么更高层的界面没有取代它

界面在变化，但组织仍然需要：

• 一种清晰、可审计的方式来定义指标和逻辑
• 通过标准与共享概念实现的跨工具、跨厂商可移植性
• 一个分析师、工程师和产品团队都能理解的共同基础技能

SQL满足了这些需求。它并不完美，但它可教可学，而可教性正是这项发明的一部分。

要点

钱伯林真正的遗产是这样的理念：最好的工具让强大的系统变得可接近。当一门语言可读时，它会吸引更多人参与讨论——而技术正是通过这种方式从实验室走向日常工作。