如果让程序员们投票选举：“过去50年最成功的软件抽象是什么？”
我觉得前三名大概率是：
1.TCP/IP
2.Unix & C
3.SQL
SQL能位列3甲，是因为它完成了一件几乎不可能的事：几十年来，硬件、软件、框架、类库换了一波又一波，开发方式从单机，到局域网，到互联网，再到移动互联网，云计算，但是SQL一直没变。
你随便翻开一本1995年出版的数据库教材，找到类似的查询：
ORDER BY headcount DESC;把它粘贴到 2026 年的 PostgreSQL 18 中，它依然可以运行。
同样的语法，同样的结果，同样的思维模式。
三十一年了，没有任何变化，实在是太惊人了。
相比而言，假设你有一个 2015 年的 React 组件，它使用了 React.createClass 、mixins 和 componentWillMount 。它不仅看起来老旧，而且一加载就会抛出 TypeError: React.createClass is not a function ，你现在需要从头开始重写它才能发布。
当然，SQL的发展也不是一帆风顺的，今天我们来聊聊它的历史。
0 1
SQL 诞生
大家都知道，关系数据库是IBM的研究员科德提出来的，但是SQL却不是他发明的。
科德提出了关系模型，这个模型在数学上非常漂亮。
一个关系（“表”），无论你做什么操作，选择也好，投影也好，连接也好，它的结果还是一个“表”，实在是优雅。
但是，数学的完备并不意味着好用，关系代数的符号就让人头皮发麻：
选择 ：Selection（σ）
投影 ：Projection（π）
并集 ：Union（∪）
笛卡尔积 ：Cartesian Product（×）
这些运算符号在键盘上都敲不出来。
所以，当两个新人张伯伦和博伊斯进入IBM，开始实现关系数据库System R的时候，他们立刻就注意到了这个问题。
两人把复杂的关系代数，改成了非专业人士都能理解的英语：
WHERE e.manager = m.name and e.salary > m.salary这个新语言叫SEQUEL，意思是Structured English Query Language，翻译过来就是“结构化英语查询语言”。
不巧的是，SEQUEL已经被一家英国公司注册成商标了，两人一拍脑门：换个名儿吧！于是就有了更简单、更好记的SQL。
那个时候，IBM还没打算把SEQUEL真正做成产品，就由着他们把论文拿到一个技术会议上发表。
谁去宣读呢？两人干脆用抛硬币来决定。最后博伊斯赢了，由他上台。
可谁也没想到，会议结束刚过一个月，博伊斯就因为脑瘤去世了，才27岁。真是天妒英才。
0 2
竞争对手
痛失挚友后，张伯伦没有停下脚步，他决定完成博伊斯未竟的事业。
他被任命为System R的技术经理，在System R里真正把SQL做了出来，同时还想证明一件事：关系数据库到底能不能搞定商业里那些复杂的事务处理。
就在差不多的时候，UC Berkeley也在做类似的事情。
他们开发了一个叫Ingres的关系数据库，目标一样，但路子不一样——他们专门设计了一套自己的查询语言，叫QUEL。
delete s where s.name="liuxin"时间一晃到了80年代，计算机价格一路往下掉，终于跌到了一个临界点：很多公司都买得起计算机和软件了，纷纷想把纸质的表格塞进电脑里存储。
数据库的需求一下子就爆了。因为“表”这东西特别好理解，基于关系数据库写程序也变得简单起来。
System R和Ingres都挺成功，但问题来了——SQL和QUEL，到底谁能笑到最后？
0 3
Oracle 立功
这时候，在科德所在的那个城市圣何塞，一个叫Larry的年轻人出手了，一下打破了天平。
Larry看到了科德的论文，也看到了SQL的论文，他被震撼了：关系数据库，绝对是未来。
他二话不说，拉上两个朋友，成立了一家小公司，他自己掏了1200美元，朋友凑了800美元，开始基于VAX小型机搞关系数据库。
深受张伯伦和博伊斯论文影响的他，自然选择了SQL。
1979年，Oracle正式问世。Larry靠着自己的人脉，开始向美国海军、CIA这些部门推销。
他到处吹牛：“我们的数据库不需要IBM的大型机就能跑，价格便宜，还用上了最先进的SQL！”
更骚的是，Oracle 当时发布的第一个版本直接叫：Version 2，没有 Version 1。
为什么这么干？
因为客户觉得Version 1 肯定有Bug，于是 Larry Ellison 干脆跳过 Version 1，直接卖 Version 2。
结果客户一看：哟，都迭代到第二版了，成熟，可以买。
这个骚操作后来成了软件史上的经典案例。
Oracle 在美国政府中的应用非常成功，以至于美国政府发布了一个联邦信息处理标准，指定在联邦数据库中要使用SQL，而不是别的查询语言！
得到官方认证的SQL击败了QUEL，成为了最终的胜利者。
很快，SQL被ANSI, ISO等重磅机构采纳为正式标准。
没想吧，现在恶名累累的Oracle居然对SQL的普及做过重大的贡献。
0 4
回归王位
关系数据和SQL在八九十年代横扫市场，占据了主流。
时间很快来到2010年，Web 2.0火得一塌糊涂。
用户生成内容（UGC）爆炸，社交关系，Feed流，动态墙......这些东西和传统表格不一样：一个用户的资料里可能有地址、兴趣、好友列表，结构不但经常变，还带嵌套，每个人可能都不一样。
如果用传统的关系型数据库，得设计好多张表，还要考虑怎么连（JOIN），改个字段甚至要停机。
所以JSON格式开始流行了。
}前端用JSON，API返回JSON，大家自然会有一个问题：为什么数据库不是JSON？
自然而然，像MongoDB这样的文档数据库就开始兴起了。
关系数据库受到了重大打击，支持文档数据库的阵营甚至起了个名：NoSQL。
意思是不要SQL！
NoSQL 运动是 SQL 所面临的最严峻挑战，MongoDB、 CouchDB 、DynamoDB 和 Cassandra 都押注文档型数据库和键值数据库将取代关系型数据库模型。
在那几年时间，“直接用 MongoDB”几乎成了 Stack Overflow 上很多问题的答案。
但是很快大家就发现，文档数据库并不能“取代 SQL”。
因为缺乏模式（表结构）、数据完整性约束很弱、对事务的支持很弱，甚至干脆没有， 这引起了程序员的强烈不满和抗议，慢慢地，SQL又回来了。
Snowflake，以 SQL 为核心。
BigQuery，以 SQL 为入口。
Databricks，把 SQL 做成了一等公民。
连 Spark，也专门做出了 Spark SQL。
甚至很多 NoSQL 数据库最后都偷偷加上了 SQL 查询层。
SQL 没死，反而把敌人同化了。
0 5
AI喜欢SQL
最近两年有个很有意思的现象，大模型写Java、C++、Python时容易出错，偶尔胡编，但是写SQL往往表现很好。
这可能有两个原因：
1.SQL是声明性语言，告诉模型 “做什么”（What）
例如：SELECT name FROM users WHERE age > 18
模型只需要理解：目标=取name，条件=age>18，来源=users表。
这是一个小范围、映射关系明确的任务。数据关系清晰（表、列、行），逻辑相对线性。
Java/C++（命令式/过程式）：告诉模型 “怎么做”（How），还要考虑状态、副作用、异常处理、内存管理……
2.SQL的“语法空间”和“语义空间”非常小
SQL的关键字只有几十个，语法规则相对固定。模型要生成的“符号”种类有限。
对比Java：有上千个标准库类、成百上千的方法、复杂的泛型和并发模型。模型犯错的空间极大。
既然AI能把SQL写好，那我们还需要去学习SQL吗？
答案是肯定的，因为AI虽然擅长写语句，但是人类必须理解语义，“销售额”是订单创建时间还是支付时间？是否排除退款？是否按税前金额计算？
这些决定结果对不对，而不是 SQL 写得像不像，人类必须判断性能和正确性。
热门跟贴