系统与数据库2024research.google
SQL 中的管道语法
Pipe Syntax in SQL
入门 · 约 45 分钟读完前置知识：SQL 基础、关系代数基本概念
导读
Google 发表的论文提出 SQL 的管道（pipe）语法，通过 FROM 开头、用 |> 串联 WHERE/AGGREGATE/ORDER BY 等操作符的方式重写查询，解决传统 SQL 子句顺序固定、逻辑书写顺序与执行顺序不一致导致的可读性问题。该语法已在 Google SQL 方言中实现。
HN 关注点：SQL 语法设计是 HN 的经典争论话题，Google 官方下场'修 SQL'引发了对是否还称得上 SQL、与 PRQL 等已有方案对比的讨论。
HN 评论精选
这几条评论里：质疑 3 补充 1
质疑展示管道语法示例，质疑其是否还算 SQL，但承认可读性提升
从 PDF 里举了个例子：FROM r JOIN s USING (id) |> WHERE r.c < 15 |> AGGREGATE sum(r.e) AS s GROUP BY r.d |> WHERE s > 3 |> ORDER BY d |> SELECT d, s, rank() OVER (order by d)。这样调整子句顺序之后还能叫 SQL 吗？PRQL 等也做过类似的事，但它们没自称 SQL。不过我确实觉得这样更易读。
Ciantic查看英文原文
Here is one example from the PDF: FROM r JOIN s USING (id) |> WHERE r.c < 15 |> AGGREGATE sum(r.e) AS s GROUP BY r.d |> WHERE s > 3 |> ORDER BY d |> SELECT d, s, rank() OVER (order by d) Can we call this SQL anymore after this? This re-ordering of things has been done by others too, like PRQL, but they didn't call it SQL. I do think it makes things more readable.
质疑质疑复杂 SQL 的必要性，主张用其他语言做数据转换
想问写复杂 SQL 的人：为什么不写简单查询、再用别的语言做转换？SQL 引擎在过滤/匹配/聚合上真的比应用层更高效吗？没有可复用模块、测试和日志，开发不是更难吗？语法是一回事，性能和安全可维护性是另一回事。
mocamoca查看英文原文
Question for people writing highly complex SQL queries. Why not write simple SQL queries and use another language to do the transformations? Are SQL engines really more efficient at filtering/matching/aggregating data when doing complex queries? Doesn't working without reusable blocks / tests / logs make development harder? Syntax is one thing, but actual performance (and safety/maintenance) is another deal?
质疑20 年 SQL 老手反驳'SQL 有缺陷'论，认为问题在工具而非语言
我很怀疑那些坚称 SQL 有缺陷的人，花在'修 SQL'上的时间是否比实际使用它的时间还多。写了 20 年 SQL 后我相信这门语言远超它的时代，我们才刚开始看到合适的工具生态——Azure Data Studio 加 Copilot 让以 select 开头写查询变得非常自然，相比之下这种管道语法显得很原始。
gfody查看英文原文
I seriously wonder if the people who are so adament that sql is flawed have spent as much time using at as they have trying to "fix" it. After 20 years of sequeling I have come to believe that this language is so far ahead of its time that we're only just beginning to see what a proper tooling for it looks like. Azure Data Studio w/Copilot makes starting queries with "select" the most natural thing in the world and this pipe syntax is barbaric in contrast.
补充吐槽论文只有 PDF 不便阅读
Google：你是一家互联网公司，请学会把研究论文发布成网页。
simonw查看英文原文
Google: you are a web company. Please learn to publish your research papers as web pages.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2024Hacker News 讨论帖308 分 · 229 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选