编程与软件工程scattered-thoughts.net
反对 SQL
Against SQL
2021 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 scattered-thoughts.net 上的一篇长文，系统批评 SQL 作为关系数据库查询语言的种种缺陷，并反过来推导一个更好的替代语言应具备哪些特性。作者的核心立场不是 SQL 完全不能用，而是认为替换 SQL 可能释放巨大价值；文章偏技术，给出了问题清单和设计方向，但没有给出完整的新语言实现。
为什么经久不衰：它把“SQL 够用所以没人换”与“SQL 确有历史包袱”之间的张力讲清楚了，是讨论数据库查询语言设计时绕不开的经典批评。
HN 评论精选
文章太技术化，容易被 SQL 老手用“够用就好”挡回去，但作者同意 SQL 值得被更好的方案取代。
这篇文章的问题在于太技术化：只有对 SQL 足够熟悉的人才会读完，而这些人要么已经接受 SQL 最终能把活干完，要么学会了与它共处甚至喜欢它，于是抓住例子不好来否定批评。但文章的核心观点——替换 SQL 可能释放巨大价值——其实说得不错。很多人用“完美是好的敌人”为 SQL 辩护，说它虽然不讨喜但大家都能接受。对个人来说重造轮子成本太高；大公司里工程师也都熟悉 SQL。但对关系数据库这么重要的东西，完美不该是好的敌人，我们值得更好的。SQL 对非技术用户不友好，可视化语言如 Airtable 可能更好；对技术用户也别扭古怪。
slx26查看英文原文
I think the problem of this essay is that it's overly technical: only those versed well enough in SQL will really care to read the whole thing, and if they are already at that level, either they accepted that "SQL will get the job done in the end", or they learned to live along it and now even kinda embrace it, and are happy to write about how the examples are very poor and dismiss the critique based on that, when the essay kinda explains it main point pretty well: >> The core message [...] is that there is potentially a huge amount of value to be unlocked by replacing SQL To me, a lot of people defends SQL saying that "perfect is the enemy of good" and that SQL simply works. Not the favourite of anyone, but everyone kinda accepts it. And yeah, it's true. People use SQL because it's good enough, and trying to reinvent the wheel would take more work (individually speaking) than just dealing with SQL as it is right now. For large organizations where the effort could be justified, all your engineers already know SQL anyway, so it's not so great either. But for something so relevant as relational databases, perfect is not the enemy of good. We do deserve better. We generally agree that SQL has many pitfalls, it's not great for any kind of user (for non-technical users, a visual programming language would work well here, more like what Airtable does, closing the bridge between spreadsheet and hardcore database, and for technical users, it does feel unwieldy and quirky). We should be more open to at least consider critiques and proposals for better. We might find out that people, from time to time, are making some good points.
更丰富的抽象可能拖累查询优化器，替代方案应保持声明式、可优化，或许拆成查询语言和过程语言两层。
我想知道这些限制中有多少是必要的，以便查询优化器有机会找到好的执行计划。当你在查询中间加入越来越多的抽象和通用计算，优化器会越来越难理解你真正想做什么并高效执行。你难道不是在冒数据库只能盲目全表扫描、把用户定义函数当黑盒逐行调用的风险吗？我也猜我们可以有更好的 SQL，但不认为它应该像通用编程语言，否则会妨碍高效执行。也许应该是一种声明式数据流描述，有足够设施来命名和复用片段。也许你其实需要两种语言，SQL 的过程部分已经有点像：一种受限但可优化好的语言来访问数据，一种更通用的语言做额外处理而不用离开服务器。SQL 的真正问题可能主要在过程部分及其与查询部分的接口。
danbruc查看英文原文
I wonder how much of the limitation are necessary in order for the query optimizer to have any chance at finding a good execution plan. As you add more and more abstractions and more and more general computations in the middle of your queries, it will probably become harder and harder for the query optimizer to understand what you are actually trying to do and figure out how to do it efficiently. Are you not running the risk that the database will have to blindly scan through entire tables calling your user defined functions as black boxes on each row? I would also guess that we could have a better SQL but I do not think it could and should look anything like a general purpose programming language because otherwise you might get in the way of efficient query execution. Maybe some kind of declarative data flow description with sufficient facilities to name and reuse bits and pieces. And maybe you actually want two languages which SQL with its procedural parts already kind of has. One limited but well optimizable language to actually access the data, one more general language to perform additional processing without having to leave the server. Maybe the real problem of SQL lies mostly in its procedural part and how it interfaces and interacts with the query part.
多数 SQL 痛苦来自错误的数据模型；先和业务方把规范化 schema 设计对，再谈性能优化。
我觉得大多数对 SQL 的挫败感，归根结底是在跟糟糕的 schema 较劲。当你坐在一个正确规范化的数据库上，写 join 和 view 来组合更高阶查询会容易得多。如果你在做各种自连接或其他递归/分支的疯狂操作，通常问题不在 SQL 本身。当初在会议室里和业务专家坐下来设计的人，很可能把关系模型搞错了，你的痛苦最终要怪他们。如果有机会重做 schema，前几次别直接在数据库里做。先在 Excel 里搭出来，和利益相关者来回推敲几周。等所有参与者都理解并认可事物为什么这样（相关地）组织，再开始原型实现。达到 3NF 或更好，通常是确保任何有意义的复杂 schema 不随时间失控的基本要求。只有先把（事实/类型/关系）搞对，才该考虑你刚建模的东西会有什么性能问题。过早优化是 99% 情况下把自己坑惨的方式。先正确建模，然后如果性能无法通过基本索引或应用层批处理/缓存解决，再考虑优化。
bob1029查看英文原文
I feel like most frustrations with SQL boil down to fighting against a shitty schema. When you are sitting in a properly normalized database, it is a lot easier to write joins and views such that you can compose higher order queries on top. If you are doing any sort of self-joins or other recursive/case madness, the SQL itself is typically not the problem. Whoever sat down with the business experts on day 1 in that conference room probably got the relational model wrong and they are ultimately to blame for your suffering. If you have an opportunity to start over on a schema, don't try to do it in the database the first few times. Build it in excel and kick it around with the stakeholders for a few weeks. Once 100% of the participants are comfortable and understand why things are structured (related) the way they are, you can then proceed with the prototype implementation. Achieving 3NF or better is usually a fundamental requirement for ensuring any meaningfully-complex schema doesn't go off the rails over time. Only after you get it correct (facts/types/relations) should you even think about what performance issues might arise from what you just modeled. Premature optimization is how you end up screwing yourself really badly 99% of the time. Model it correctly, then consider an optimization pass if performance cannot be reconciled with basic indexing or application-level batching/caching.
厂商和生态缺乏替换动力：数据库迁移成本高，ODBC/JDBC 等标准绑定 SQL，没有杀手级特性推动行业换语言。
这些大多都对，但 RDBMS 厂商几乎没有动力去实现和维护第二种查询语言，尤其是一种跨厂商共享的语言。数据库是 IT 系统里寿命最长、迁移成本最高的依赖，所以长期并行保留基于 SQL 的接口会是强制性的。标准化且以 SQL 为中心的数据库驱动 API（如 ODBC 和 JDBC）又加剧了这一点。尽管 SQL 有缺点，但并没有真正的杀手级特性能触发全行业协调一致的改变。
layer8查看英文原文
This is mostly all true, but there is little incentive for RDBMS vendors to implement and maintain a second query language, in particular a shared cross-vendor one. Databases are the most long-lived and costly-to-migrate dependencies in IT systems, so keeping the SQL-based interface in parallel for a long time would be mandatory. This is compounded by the standardized SQL-centric database driver APIs like ODBC and JDBC. Despite the shortcomings of SQL, there is no real killer feature that would trigger the required concerted change across the industry.
历次讨论
同类还值得读
开源应用架构
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编辑精选