在最近一篇题为“SQL 有问题,我们可以解决”(SQL Has Problems. We Can Fix Them)的论文中,谷歌的一个研究团队建议在 SQL 中引入新的管道语法。谷歌为解决 SQL 被认为存在的局限性而提出的这一解决方案目前已在 GoogleSQL 和 ZetaSQL 方言中提供,但社区对此的反馈却褒贬不一。
为了解决 SQL 的设计挑战并使其成为一种更灵活的语言,谷歌的研究团队提出通过引入管道数据流语法来扩展 SQL。这种设计遵循了与 MongoDB 查询语言 等新兴数据语言相似的模式。谷歌的软件工程师 Jeff Shute 及其同事写道:
我们不必容忍 SQL 的缺陷。这种语言是可以修复的!本文展示了如何借鉴其他语言和 API 的灵感,将管道结构化数据流添加到 SQL 中,而且只需可接受的开销。由此产生的语言依然是 SQL,但却是更好的 SQL。它更灵活、更可扩展,也更易于使用。
传统 SQL 将操作组合成一个语句,而管道式 SQL 则将其拆分为一系列步骤。例如,以下查询:
现在可以写成:
作者和其他专家认为,采用 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 数据英雄。
原文链接:
评论