我一个前同事 Mosha Pasumansky，也是MDX语言的发明人之一，最近在Linkedin上高调发文，盛赞了一篇谷歌VLDB文字：SQL Has Problems. We can fix them：Pipe Syntax In SQL 。

这一段信息密集度有点高。先说一下我这个前同事 Mosha Pasumansky。这个人最牛逼的成就就是联合发明了MDX。MDX是数仓常用的查询语言。后来他在微软Cosmos和谷歌Big Query都干过，最近成了Firebolt的CTO。Firebolt是一家著名魔改Clickhouse的云数仓创业公司。VLDB估计大家也都知道是啥了，数据库领域的一个顶级会议。

而这篇文章，是谷歌发的一篇文章，里面主要讲了谷歌怎么样修复SQL的毛病。那么谷歌说的SQL的毛病是什么呢？说直白一点，就是SQL这语言，只要跨过了最简单的语法结构之后，就特别难读了。如果你需要写有很多子查询的SQL的话，大概率是很难懂的。比如说基于TPC-H的下面的查询：

SELECT COUNT(*) AS custdistFROM ( SELECT COUNT(o_orderkey) AS c_count  FROM customerLEFT OUTER JOIN orders                ON c_custkey = o_custkey AND
 o_comment NOT LIKE '%unusual%packages%'                    
GROUP BY c_custkey) GROUP BY c_count  ORDER BY custdist DESC, c_count DESC;

要我看起来，反正是不太好看，毕竟套了一层子查询。就这种查询来说，在现代实际业务中的SQL是小儿科了。

要是有机会打开银行后台的各种存储过程看看，那你要能够读得津津有味，简直就是神仙了。一般人要想折腾复杂SQL，那还真的不是一件特别容易的事情。所以谷歌表示，SQL有毛病了。。。。

谷歌是怎么修的呢？引入管道的概念。管道在UNIX系列操作系统里面是很熟悉的，比如说上面的那个复杂查询可以按照下面的写法来写：你要是不懂什么意思呢简单来说，管道就是把第一句话的结果通过管道操作符定向成为第二句话的输入。这里FROM customer就表示对customer表全表扫描的结果成为下一句话的输入，以此类推。

当然，这不是个新鲜玩意。管道不是新鲜玩意，而使用管道来进行输入输出串联的语言也不是个新鲜玩意。谷歌不同的地方在于，管道是一种扩充，用户既可以写传统SQL，也可以写管道SQL。所以理论上来说，老旧的SQL谷歌还是要继续支持的。因此老旧的产品也不急于一时改头换面。 谷歌的产品包括BigQuery还有Spanner估计都要全面支持新的语法了。 

Mosha大佬表示，虽然说那些老牌数据库可能很顽固，但是他觉得新的数据库比如说Snowflake或者Databricks应该有希望可以也实现这样的语法。
这个管道的东西到底是不是真的更好呢？我个人并不是很喜欢这种做法。我个人更喜欢的syntax是使用Table-Variable。简单来说，上述基于管道的写法可以这样写：

A = SELECT * FROM customer
B = A LEFT OUTER JOIN  order ON。。。C = SELECT COUNT(o_orderkey) AS c_count FROM B        GROUP BY c_custkey

当然，我喜欢与否也只是一家之言。实际上在SQL圈子里，对于谷歌引入管道，持支持和反对态度的人，都有不少。尽管大家都表示SQL病了，但是SQL应该吃什么药治病，貌似观点都不太一致。所以，我觉得谷歌这次自娱自乐的可能性，比较大。整个industry都买单的可能性非常的低。