唐纳德·钱伯林在IBM参与发明SQL,英文式语法为何重要,以及SQL如何成为查询数据库的行业标准。

唐纳德·D·钱伯林不是家喻户晓的名字,但他的工作悄然决定了大多数软件团队处理数据的方式。作为IBM的研究员,钱伯林共同创造了SQL(最初拼作SEQUEL),这门语言使得日常开发者——甚至非专业人员——也能对大型数据库提出查询。
在SQL出现之前,从存储的数据中获取答案通常需要编写定制程序或使用功能强但笨拙的工具。钱伯林推动了另一种想法:与其一步步告诉电脑如何查找数据,不如以接近普通英语的形式描述你想要的结果。
SQL的核心是一种令人惊讶地以人为本的方式:
SELECT)FROM)WHERE)现在听来显而易见,但那是一次重大转变。它把“查询数据库”从专家任务变成了可以被教授、共享、审查和改进的事情——就像软件开发的其他部分一样。
这是一个关于SQL如何诞生以及它为何广泛传播的实用历史。
你不需要高级数学、形式逻辑或深厚的数据库理论来跟上本文节奏。我们将聚焦于SQL解决的现实问题、为何其设计容易上手,以及它如何成为软件行业的默认技能——从后端工程到分析、产品和运维。
如果你曾筛选列表、对结果分组或连接两组信息,那你已经在用SQL使之主流的思维方式在思考。钱伯林的持久贡献是把这种思路转化为人们实际能使用的语言。
在SQL之前,大多数组织并不“查询数据库”。他们处理的是存储在文件中的数据——通常每个应用对应一个文件,由创建它的程序管理。薪资有自己的文件、库存有自己的文件、客户记录可能分散在多个系统中。
这种基于文件的方法能工作,直到企业需要跨界的问题:"哪些客户买了产品X并且还有未付发票?"要得到这样的视图,就必须把原本不为合并设计的数据拼接起来。
在许多早期系统中,数据格式与应用紧密耦合。某处的一个变动——比如为客户添加电话号码字段——可能需要重写程序、转换文件和更新文档。即便“数据库系统”开始出现,很多仍然暴露低级访问方法,让人感觉像在编程而不是在提出问题。
如果你想要信息,通常有两个选项:
两种选择都不利于探索。文字上的小变化——加一个日期范围、按地区分组、排除退货——可能变成新的开发任务。结果是瓶颈:有问题的人必须等待会写代码的人。
组织缺少的是一种表达数据问题的共通方式——既要对机器足够精确,又要对人足够可读。业务人员以“客户”“订单”“总额”来思考,而系统则围绕文件布局和过程步骤构建。
这种差距催生了对查询语言的需求:一种能把意图翻译为操作的、可复用的一致表达方式,而不是每次都写新程序。这个需求为SQL的突破铺平了道路。
在SQL出现之前,数据库世界需要一种更清晰的思考数据的方式。关系模型提供了这一点:一种简单一致的框架,把信息存储在表(关系)中,由行和列组成。
关系模型的核心承诺很直接:不要为每个应用构建一次性、难以维护的数据结构。相反,把数据以标准形式存储,让不同的程序无需重写数据组织就能提出不同的问题。
这次转变重要,因为它把常被缠在一起的两件事分离开来:
当这些关注点被分开后,数据更容易共享、更新更安全,也不那么依赖某个应用的特殊设计。
Edgar F. Codd 在IBM帮助形式化了这一思想,并解释了它为何优于通过固定路径导航记录的方法。你不需要完整的学术背景来理解影响:他给了行业一个可推理、可测试和可改进的模型。
一旦数据以表的形式存在,下一个自然问题是:普通人如何提出他们需要的内容?不是指向存储位置,而是描述要得到的结果。
那种“描述你想要什么”的方法——选择这些列、过滤这些行、连接这些表——为一种以人为友好的查询语言铺平了道路。SQL就是为利用那种模型而构建的,把关系理论变成日常工作。
IBM System R 最初并不是商业产品——它是一个研究项目,旨在回答一个现实问题:Edgar F. Codd 的关系模型能否在真实世界、真实规模和真实业务数据下工作?
当时,许多数据库系统通过物理访问路径和逐条记录逻辑进行导航。关系数据库承诺不同的东西:把数据存储在表中,清晰地描述关系,让系统自己决定如何检索结果。但这个承诺依赖两方面协同工作:一个高效的关系引擎和一个普通开发者(甚至一些非开发者)也能使用的查询语言。
System R 于1970年代在IBM圣何塞研究实验室开发,目标是构建一个关系数据库管理系统原型并对关系思想进行压力测试。
同样重要的是,它探索了如今已成基础的技术——尤其是查询优化。如果用户要编写高级请求(“给我这些满足这些条件的记录”),系统需要自动地把这些请求翻译成高效操作。
在IBM的研究环境中工作的唐纳德·钱伯林,专注于缺失的那部分:一种对关系数据提出问题的实用语言。他与合作者(尤其是 Raymond Boyce)一起塑造了一种与人自然描述数据需求相匹配的查询语言。
这并非在真空中设计语言。System R 提供了反馈回路:如果某个语言特性无法高效实现,它就不会存活;如果某个特性能让常见任务更容易,它会获得动力。
Codd 用形式数学(关系代数和关系演算)描述了关系模型。这些思想很强大,但对日常工作过于学术化。System R 需要一种语言,要求是:
这种基于可运行原型的寻找,奠定了SEQUEL继而成为SQL的舞台。
钱伯林与同事最初把新语言命名为 SEQUEL,意为 Structured English Query Language(结构化英文查询语言)。名称暗示了核心思想:不再编写过程代码去逐步导航数据,而是以接近日常英语的形式陈述你想要的东西。
后来将名称缩短为 SQL(部分出于实用——更短、更便于打印和发音,也与商标命名有关)。但“结构化英文”的志向仍然存在。
设计目标是让数据库工作感觉像提出一个清晰请求:
这种结构给了人们一个一致的心智模型。你不必学习某个厂商的特殊导航规则;你学会了一种可读的询问模式。
想象一个简单的业务问题:"今年哪些加州客户消费最多?" 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 能流行的一个原因是它让你以口语化的方式表达问题:"选这些内容,从这个地方,满足这些条件。"你不必描述如何一步步找到答案;只需描述想要什么。
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让你感到害怕,退一步,把你的目标用一句话重述。然后把词映射到语句:
以问题为先的习惯才是SQL“以人为友好”设计的真正内核。
SQL不仅引入了一种与数据对话的新方式——它降低了成为“数据库人”的门槛。在SQL之前,向数据库提问通常意味着编写过程代码、理解存储细节或向专家团队提交请求。钱伯林的工作帮助把局面翻转:你可以描述想要的结果,数据库负责决定如何检索它。
SQL 最大的可访问性收益在于它足够可读,可以在分析师、开发者和产品团队之间共享。即使初学者也能理解像这样的查询意图:
SELECT product, SUM(revenue)
FROM sales
WHERE sale_date >= '2025-01-01'
GROUP BY product;
你无需了解索引结构或文件布局就能看出在问什么:给定日期范围内按产品计算的总收入。
由于SQL是声明式并被广泛教授,它在规划和调试时成为共同参考点。产品经理可以校验问题(“我们是否算上退货?”)。分析师可以调整定义。工程师可以优化性能或将逻辑移入应用或数据流管道。
更重要的是,SQL让“问题”本身可被审查。它可以版本控制、注释、测试和改进——像代码一样。
SQL使得提问更容易,但并不保证答案可靠。你仍然需要:
SQL为自助式数据工作打开了大门,但良好结果仍依赖于良好数据和共享语义。
SQL之所以胜出,不是因为它是唯一的查询语言,而是因为它对一个需要共享惯例的成长中行业而言非常实用。一旦团队看到SQL可以让他们在不为每个报表编写定制代码的情况下提出清晰问题,它就开始出现在更多产品、培训和职位描述中。
随着数据库厂商加入对SQL的支持,其他软件也随之受益。报表工具、商业智能仪表盘以及后来的应用框架都因拥有一种通用的数据获取和整形方式而受益。
这产生了一个正反馈循环:
即便数据库内部不同,熟悉的SQL“表面”减少了切换系统或集成多个系统的成本。
可移植性并不等于“毫无改动即可运行任何地方”。它意味着核心概念——SELECT、WHERE、JOIN、GROUP BY——在不同产品中保持可识别。为一个系统写的查询通常只需小幅调整就能在另一个系统上运行。这降低了厂商锁定并使迁移变得不那么可怕。
随着时间推移,SQL被标准化:一套共享的规则和定义,厂商大体上同意支持它。把它想象成语言的语法。不同地区有口音和俚语,但基本语法让你可以交流。
对个人和组织而言,这种标准化带来了巨大影响:
最终结果是:SQL 成为处理关系数据的默认“共同语言”。
SQL不只是改变人们如何查询数据——它改变了软件的构建方式。一旦存在了一种通用的数据库询问方式,整类产品就可以假设“SQL 可用”,并专注于更高层的功能。
你可以在业务应用(CRM、ERP、财务系统)、报表仪表盘以及用于获取和更新记录的Web服务中看到SQL的身影。即使用户从未输入过查询,许多应用也在后台生成SQL来筛选订单、计算总额或组装客户画像。
这种普及创造了一个强大模式:如果你的软件会说SQL,它就能以较少定制集成与多种数据库系统协作。
共享的查询语言使得构建围绕数据库的工具成为可能:
关键点是,这些工具并不依赖单一厂商接口——它们依赖可迁移的SQL概念。
SQL在2025年仍然重要的一个原因是,它像意图与执行之间的持久契约。即便你用更高层的工具或AI构建应用,仍然需要一个明确、可测试和可审计的数据库层。
例如在 Koder.ai(一个通过聊天创建Web、后端和移动应用的vibe-coding平台),团队常常把“应用应该做什么”以清晰的关系表和SQL查询的形式落地。底层通常是用 Go 后端和 PostgreSQL,SQL仍然是连接、过滤与聚合的共享语言——而平台加速了脚手架、迭代和部署过程。
SQL存在数十年,也因此积累了许多抱怨。许多批评在狭窄语境下是有道理的,但人们常常在缺乏现实场景细节的情况下重复这些说法。
SQL 在你看到 SELECT ... FROM ... WHERE ... 时显得简单,但随后复杂性就来了:连接、分组、窗口函数、公共表表达式、事务、权限、性能调优。这个跃迁令人沮丧。
一个有用的框架是:SQL 在核心小而在边缘大。核心思想——过滤行、选择列、组合表、聚合——很快能学会。复杂性通常出现在你要精确处理真实世界数据(缺失值、重复、时区问题、混乱的标识)或在大规模下追求性能时。
一些“奇怪”其实是SQL对数据诚实地表达。例如,NULL 表示“未知”,既不是0也不是空字符串,所以比较行为不同。另一个常见意外是,如果你不显式排序,同一查询在不同时间可能以不同顺序返回行——因为表不是电子表格。
这些并不是放弃SQL的理由;它们提醒我们,数据库更倾向于为正确性和清晰性优化,而不是隐式假设。
这种批评混淆了两件事:
厂商会添加特性以竞争并服务用户——额外函数、不同的日期处理、专有扩展、专门索引、过程化语言。这就是为什么某个系统能运行的查询在另一个系统可能需要小改动。
先掌握可移植基础:SELECT、WHERE、JOIN、GROUP BY、HAVING、ORDER BY,以及基本的 INSERT/UPDATE/DELETE。一旦这些变自然,选择你最可能使用的数据库并学习它的特性与怪癖。
如果你自学,保留一张个人备忘单记录遇到的差异会很有帮助。这样“方言令人恼火”就会变成“我知道该查什么”,这才是日常工作的现实技能。
学习SQL不是死记语法,而是养成一种习惯:先提出清晰问题,然后把它翻译成查询。
从一张小表开始(想想 customers 或 orders),先练习读取数据再去做其它事情。
WHERE 和 ORDER BY 进行过滤和排序。练习只选择需要的列。JOIN 连接两表(例如 orders + customers)。GROUP BY 来回答“多少?”和“多少值?”的问题——计数、求和、平均、按月总计。这个进阶顺序反映了SQL的设计:把问题分成部分来表达,然后让数据库决定最优执行方式。
如果你在共享数据库上练习,或还新到会误点东西,遵循这些规则保护自己:
SELECT。 把它当作“只读模式”。LIMIT 50(或你使用数据库的等价语法),避免拉取数百万行。DELETE、UPDATE、DROP),直到你完全理解 WHERE 条件并有安全沙箱。SELECT 来验证将被更改的行。好的SQL练习看起来像真实工作:
选一个问题,写查询,然后检查结果是否合乎常识。这样的反馈循环能让SQL变得直观。
如果你在同时构建真实项目学习SQL,把模式、查询和应用代码放在一起会有帮助。例如在 Koder.ai 上快速原型一个以 PostgreSQL 为后端的小应用,你可以快速迭代表和查询、快照变更,并在准备好时导出源码——同时不会丢失实际的SQL逻辑视角。
钱伯林的持久贡献不仅在于发明语法——而在于他搭建了一座人和数据之间的可读桥梁。SQL让人们能够描述想要什么(加州客户、本月销售、库存低的产品),而不必逐步写出计算机如何去获取。这个转变把数据库查询从专家手艺变成了团队可以讨论、审查和改进的共享语言。
SQL之所以经久不衰,是因为它处在一个有用的中间地带:既足够表达复杂问题,又足够结构化以便被优化和标准化。即使新型数据工具层出不穷——仪表盘、无代码界面、AI助手——SQL仍是可靠的底层层面。许多现代系统仍把点击、筛选和提示翻译成类似SQL的操作,因为数据库可以验证、保护并高效运行这些操作。
界面在变化,但组织仍然需要:
SQL满足了这些需求。它并不完美,但它可教可学,而可教性正是这项发明的一部分。
钱伯林真正的遗产是这样的理念:最好的工具让强大的系统变得可接近。当一门语言可读时,它会吸引更多人参与讨论——而技术正是通过这种方式从实验室走向日常工作。
唐纳德·D·钱伯林是IBM的研究员,作为System R项目的一部分与人合创了SQL(最初叫SEQUEL)。他的关键贡献是帮助设计出一种声明式、易读的语言,使人们能够在不编写逐步程序的情况下向数据库请求结果。
SQL之所以重要,是因为它让数据访问变得可共享且可复用。团队无需每次都请求新程序或依赖固定报表,而是可以把查询写成可审查、可复用的工作单元,从而加快探索速度并减少瓶颈。
声明式语言让数据库知道你想要什么结果,而不是如何一步步去获取它。实际效果是你描述列、表、过滤条件和分组,数据库会通过查询优化器选择高效的执行计划。
基本心智模型是:
SELECT:你想看到什么(列或表达式)FROM:这些数据来自哪(表/视图)WHERE:哪些行符合条件(过滤)在掌握这些之后,你可以添加 JOIN 来连接表,GROUP BY 做汇总, 排序。
JOIN 会基于匹配条件(通常是共享标识如 customer_id)把两个或多个表的行组合起来。当你需要的信息分布在多个表中(例如订单表和客户表),就要使用 JOIN。
GROUP BY 用于按类别生成“每类”的结果(例如按客户汇总总额、按月份计数、按产品统计收入)。一个实用流程是:
SELECT ... FROM ... WHERE ...。COUNT()、SUM()、AVG()。System R 是IBM在1970年代的研究原型,旨在证明关系型数据库能否在真实规模和真实业务数据下工作。它也推动了关键技术的发展,尤其是查询优化,这使得像SQL这样的高级语言在性能上成为可能。
SQL之所以从IBM研究语言变成行业默认,是因为它成为了数据库和工具之间的通用接口。产生了一个自我增强的循环:
尽管不同产品间有差异,但核心概念保持可识别。
SQL方言确实存在,但最有效的做法是:
SELECT、WHERE、JOIN、GROUP BY、ORDER BY 以及基础的 。安全上手并分层练习:
SELECT,把它当作“读取模式”。LIMIT(或相应语法),避免一次拉出大量行。ORDER BYGROUP BY 指定你要按哪些列分组。INSERT/UPDATE/DELETE这样把不兼容性变成可查的事项,而不是持续的阻碍。
UPDATEDELETEWHERESELECT目标是把清晰的问题翻译成查询,而不是孤立地死记语法。