编程与软件工程edgedb.com
我们可以做得比 SQL 更好
We Can Do Better Than SQL
2019 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 EdgeDB 博客文章认为 SQL 在语法一致性、正交性和表达力上仍有明显不足，并展示了他们设想中的改进方向（EdgeQL）。文章通过具体查询例子对比 SQL 的冗余与不一致，主张可以设计出更现代、更少历史包袱的查询语言。
为什么经久不衰：SQL 统治数据领域数十年，替代方案必须同时面对表达力、关系代数基础和生态惯性；这篇及其引发的争论是理解这些取舍的经典样本。
HN 评论精选
反对把 select 嵌入表表达式而模糊多值膨胀，肯定 SQL 的关系代数基础，但支持 FROM 前置的语法改进。
我不买账。文中一个例子让我印象深刻：作者想把 select 嵌入表表达式。我一点也不喜欢。我不希望一个表达式列表是否会膨胀成多值变得不清楚。我喜欢 SQL 有关系代数这一坚实基础，而替代方案我看不到这样的基础。我确实喜欢 LINQ 的做法（类似 SQL），把 FROM 子句放前面。有些 SQL 变体的 WITH 子句很方便，但最后会写成：WITH(...) AS a, (...) AS b SELECT a.a1,b.b1 FROM a JOIN b ON a.a=b.b。常见替代是 SELECT ... FROM (...) a JOIN (...) b ON ...，而我更希望：FROM (...) a JOIN (...) b ON ... SELECT ...
cletus查看英文原文
Yeah I'm not sold. One example from this post that struck me was the author wanted to embed a select in a table expression. I'm not a fan of this at all. I don't want it not to be clear if a given expression list will explode in values or not. I like the fact that SQL has a solid foundation in relational algebra. I see no such foundation for the alternative. I do like what LINQ did here (being SQLish), which was to put the FROM clauses first. Some SQL variants have WITH clauses that are quite convenient but you end up with: WITH (...) AS a, (...) AS b SELECT a.a1, b.b1 FROM a JOIN b ON a.a = b.b Common alternative: SELECT a.a1, b.b1 FROM (...) a JOIN (...) b ON a.a = b.b whereas I'd prefer: FROM (...) a JOIN (...) b ON a.a = b.b SELECT a.a1, b.b1
新语言应转译到成熟 SQL 数据库，复用复制、优化、锁、高可用等企业级能力，而不是重造服务器。
如果问题出在语言，为什么要写一个新服务器？把你的语言转译成等价 SQL，依赖几十年的研究和真实世界经验——复制、优化、锁策略、高可用、安全等等，这些与语言无关、现有 SQL 数据库真正擅长的事。企业需要企业级功能。
JackFr查看英文原文
If the language is the problem, why write a new server? Transpile your language to the equivalent SQL, and rely on decades of research and real world experience in things like replication, optimization, locking strategies, high availability, security etc. the things unrelated to the language current SQL databases are really good at. Enterprises need enterprisey features.
替代 SQL 门槛极高：既要覆盖大量真实 OLTP/OLAP 任务，又要具备 SQL 不可能有的能力。
我不为所动，有两个原因：1. 任何想做出更好 SQL 的人，都应该先列出一份全面的常见（但困难）OLTP 和 OLAP 数据库任务清单。这会暴露他们语言的弱点。SQL 有 50 年和无数改进来覆盖这些常见场景。这不是公平竞争，所以要有备而来。2. 仅仅“比 SQL 好”不足以取代它。SQL 有巨大的惯性，新语言必须绝对更好，而且要有许多 SQL 不可能具备的特性。我的愿望清单包括可预测的性能、锁顺序、所有权关系（便于数据清理），以及查询优化器可输出的标准低级语言。
ckocagil查看英文原文
I'm not impressed for two reasons: 1. Anyone striving to build a better SQL should make a comprehensive list of common (but difficult!) database tasks for OLTP and OLAP workloads. This will expose the weakness of their language. SQL has had 50 years and myriads of improvements to cover all these common cases. This is not a fair fight, so come prepared. 2. It's not enough to be just "better than SQL" to replace it. SQL has such a huge momentum that a new language needs to be absolutely better _and_ it should have many features that SQL cannot possibly have. My nice-to-have list would contain predictable performance, lock ordering, ownership relations (for easy data cleanup), and a standard low level language which the query optimizer would output.
批评作者一边抱怨 SQL 不一致一边推出自己的方言；其正交性例子回避了一对多边界，结果可能不再是关系表而是 dataframe。
抱怨不同版本和数据库之间语法不一致，然后推出自己古怪的分支，这相当傲慢——好像其他版本不是出于同样理由、带着同样崇高的妄想被引入似的……SQL 之所以乱，是因为描述底层数据关系本身就乱。正交性例子很好地说明了这点：如果有多个部门负责人，结果到底应该是什么？结果行要重复吗？不清楚 edgeQl 会怎么处理（他们的 edgeQl 正交性例子被构造成每个子查询只有一个结果），但看起来它们会作为集合保留在一起。那样结果集就不再是表，而是 dataframe——这是有用的数据结构，但不是关系数据库做的事。
tqi查看英文原文
It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should the result be if there are multiple dept heads? Should the result rows be duplicated? It's not clear how edgeQl would handle either (their edgQl orthogonality examples were constructed to only have result per sub query), but it seems like they would be kept together as sets. In that case, the result set is no longer a table, it's a dataframe, which is a useful data structure but is also not what relational databases do.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选