现代关系查询语言该长什么样？
Things I want in a modern relational query language
我重新整理了一篇尘封多年的草稿，探讨现代关系查询语言应有的模样。SQL 虽强大，却常因陈旧的实现方式而显得笨拙，这也是 NoSQL 兴起的原因之一。我认为，一种能从 SQL 汲取教训的语言，能让程序员更轻松地操作关系数据。我结合在 MySQL、Db2 等数据库中的实战经验，提出了几点改进设想：更友好的语法、对函数式编程更友好的设计、更透明的查询优化器、更强大的用户自定义类型，以及支持 Sum types 和模式匹配等现代特性。这些改进旨在让查询语言更简洁、更直观，减少错误，让数据操作回归本质。
程序员就像蹒跚学步的幼儿，他们想要 Kraft Dinner，而不是西兰花。
HN 评论区
107- scythmic_waves
这里和我最喜欢的一些关于 SQL 为何不足的文章有些重叠：
https://www.scattered-thoughts.net/writing/against-sql
那篇特定的文章结尾列出了一份愿望清单，所以它最接近 OP 的帖子。但该网站上还有其他我很喜欢的文章（点击主页图标并在页面上搜索 "SQL"）。
我个人的看法是，SQL 将继续统治很长一段时间，因为数据库固有的复杂性使得替换它的任务极其艰巨。LLM 让情况变得更糟，因为它们非常擅长将自然语言翻译成 SQL。既然 SQL 对程序员来说有多烦人已经不那么重要了，随着时间的推移，SQL 将变得越来越像汇编语言：主要是由计算机编写，因为人类直接处理它太复杂了。这极具讽刺意味，因为 SQL 的设计初衷显然是为了读起来像自然语言，即易于人类理解。
- burakemir
我真的很想知道 OP 和其他人如何看待 Mangle Datalog 在这个语境下的表现。Go 实现在这里：https://codeberg.org/TauCeti/mangle-go，Rust 实现在这里：https://codeberg.org/TauCeti/mangle-rs
这些实现的性能并不高，但如果你能将所有数据放入内存，或者通过外部查询来组织数据并集成它们，那么对于很多用例来说，你应该能得到一个可用的方案。
我最初的目的并不是要替代 SQL，虽然我不介意它被采用，但这不是我在这里分享它的原因。开源的动机是为了让 Datalog 被更广泛地知晓。我做了一些研究，发现我需要一种具有特定特性的 Datalog 实现，我肯定知道我不想在需要的时候使用 SQL。
它有结构化类型、递归、能够命名谓词以及组合查询等功能……Mangle 已经有一些用户，也有几个应用程序利用了这种“查询即逻辑编程”的方法。
我认为从这个讨论中可以得出的一个见解是，当涉及到不可避免的性能需求时，查询语言与其所属的系统（DBMS 实现）几乎是不可能分开的。
- bastawhiz
作为一个元评论，我可以处理没有语法高亮的代码块，也可以处理自动换行的代码块。但如果两者同时出现，再加上长评论，那就变成了乱码。再也没有任何有用的视觉信号来指导如何阅读它们了。在我的手机上，代码块根本无法有意义地解析。
- mcc1ane
https://www.geldata.com/blog/we-can-do-better-than-sql
(https://news.ycombinator.com/item?id=24106608, https://news.ycombinator.com/item?id=19871051)
- weitendorf
听起来很像 Spark 在变得如此企业化之前的样子。在我那个年代，我们写 Scala 来运行查询，一旦我们搞定了编译器和运行时的设置，我们就很喜欢它！
最近我开始研究 Postgres，让我非常惊讶的是，通过 C 代码引入新类型/运算符等是多么容易。我不是在说 domain（域）。只需写一些 C 代码，你就可以拥有你想要的任何类型。这真的让我对“扩展”祛魅了，我实际上认为这是一个具有误导性的名字（听起来笨重、恶心，基于我在其他地方处理“扩展”和“插件”的经验），因为它本质上只是自定义类型/函数。应该让更多人尝试编写自己的 Postgres 扩展。这其实一点也不难！
我在这个领域已经折腾了相当长一段时间（HDFS/Spark, Apache Pinot, 专有软件，以及一个基于 SQLite 的实验性函数式 ORM）。我认为最大的问题在于管理/管理、应用程序和“查询”层之间的接口。我认为需要像 grpc/protoc（或者 Spark 使用 JVM 的方式）这样的东西，来提供无泄漏的抽象，以及从数据库到客户端的更程序化/结构化的接口。我很乐意分享更多，但基本上，我认为数据库需要具备通用（元）解析能力，并拥有一个反射类型系统。
- mikewarot
我的请求是 15 年前的 [1]，一个实时 SQL 扩展。允许查询成为对数据库的订阅，这样任何更新都会作为增量（deltas）流式传输给监听客户端。在我使用 SQL 的过程中，有无数次都是反复运行同一个查询，只是为了获取/处理那个增量。
一开始就采用这种方式工作不是会高效得多吗？
[1] http://livesql.org/ <--- 只是 2011 年的几段文字
- nylonstrung
PRQL 在我看来是尝试新查询语言的最佳方案之一。
我正在开发一个基于 Lean4 的查询语言，它可以编译为 substrait。我认为它在类型系统和函数式编程方面的能力可以极大地改善 SQL 的人机交互体验。
- 3eb7988a1663
谁能给我解释一下为什么 SQL 的错误信息这么烂？我经常遇到一些巨大的查询，错误信息基本上就是“某处语法非法，笨蛋”。