作者 | Renato Losio
译者 | 刘志勇
审校 | 张卫滨
在最近一篇题为“SQL 有问题，我们可以解决”（SQL Has Problems. We Can Fix Them）的论文中，谷歌的一个研究团队建议在 SQL 中引入新的管道语法。谷歌为解决 SQL 被认为存在的局限性而提出的这一解决方案目前已在 GoogleSQL 和 ZetaSQL 方言中提供，但社区对此的反馈却褒贬不一。
为了解决 SQL 的设计挑战并使其成为一种更灵活的语言，谷歌的研究团队提出通过引入管道数据流语法来扩展 SQL。这种设计遵循了与 MongoDB 查询语言 等新兴数据语言相似的模式。谷歌的软件工程师 Jeff Shute 及其同事写道：
我们不必容忍 SQL 的缺陷。这种语言是可以修复的！本文展示了如何借鉴其他语言和 API 的灵感，将管道结构化数据流添加到 SQL 中，而且只需可接受的开销。由此产生的语言依然是 SQL，但却是更好的 SQL。它更灵活、更可扩展，也更易于使用。
传统 SQL 将操作组合成一个语句，而管道式 SQL 则将其拆分为一系列步骤。例如，以下查询：
SELECT name, price FROM products WHERE price > 10;
现在可以写成：
products | WHERE price > 10 | SELECT name, price;
作者和其他专家认为，采用 SQL 的管道语法可以带来多种实际好处，包括提高代码的可读性和可维护性、更好的工具和 IDE 支持，以及提高工作效率。由于新语法旨在简化 SQL 查询的编写、读取和维护过程，因此可以加快开发周期，使查询结构更直观，更容易理解和修改。
来源：谷歌研究
目前，GoogleSQL 支持管道语法，这是一种 SQL 方言，用于 Google 的多个不同的 SQL 产品，包括 BigQuery、Spanner、F1、Bigtable、Dremel 和 Procella，既用于公开产品，也用于内部产品。Shute 及其同事总结道：
管道语法开启了全新的 SQL 使用方式、提升 SQL 工具的机会以及未来的语言创新（……）。取代 SQL 既不必要，也不理想，更不现实。我们可以从语言内部解决 SQL 最严重的问题。
谷歌并不是唯一一家采用管道式 SQL 的超大规模云服务提供商；微软也在 Azure Data Explorer 和使用 Kusto Query Language (KQL) 的 Fabric KQL DB 中提出了类似的做法。SQLite 的创建者 Richard Hipp 对此 并不十分认可，YugabyteDB 的数据库专家兼开发者倡导者 Franck Pachot 则认为这并 不是什么好主意。Pachot 写道：
这种管道语法在编写简洁 SQL 代码方面非常糟糕（……）。在所有语言中，以函数的签名、名称、输入参数和返回类型作为开头是有充分理由的（……），SQL 查询也是如此。SELECT 子句定义了返回给程序的内容：表格结果的列及其名称（……）。你能用管道语法查看上面的查询吗？你该如何猜测结果的结构？
在 Reddit 上的一个热门话题中，用户 Jabes 评论道：
我认为这看起来非常有趣。如果我的数据库能够支持它，并且假设优化器仍能将语句作为一个整体来考虑，我愿意试一试。我在想，是否有可能实现一个翻译层。
新语法也可用于 GoogleSQL 的开源版本 ZetaSQL。
作者简介
Renato Losio，拥有丰富的云架构师、技术负责人和云服务专家经验。他目前居住在柏林和的里雅斯特之间，远程担任首席云架构师。他的主要兴趣领域包括云服务和关系数据库。他是 InfoQ 的编辑，也是公认的 AWS 数据英雄。
原文链接：
https://www.infoq.com/news/2024/09/google-sql-pipe-syntax/
下载量超 5000 万的知名应用，开发团队“全军覆没”，从此发版人唯剩老板一个
突发！上交所系统被买崩了？股票交易量火爆挤瘫系统，IT 部门天塌了！
AIGC 使编程平民化，将会是软件行业的一场“灾难”？| 专访 Uncle Bob
一次 App 更新差点要了这家 22 年老牌公司的命：忽视技术债、疯狂裁员降本，CEO 为开发加速无视员工警告返回搜狐，查看更多
责任编辑：