SQL 之后，GQL 成为 ISO/IEC 国际标准数据库语言项目

今年 6 月，隶属 ISO/IEC 联合技术委员会 1(负责定制 IT 标准)的全球诸多国家性标准机构开始就 GQL 项目提案进行表决，有七个国家派出专家参与这项为期四年的项目。在本周投票结束，提案获得通过。

共有十个国家投出了赞成票，其中包括中国、韩国、瑞典、美国、德国、英国、荷兰、丹麦、哈萨克斯坦、加拿大和芬兰。另外有五个国家选择弃权，其理由是缺乏对该提案作出判断或发表评论的专门知识。

只有日本投了反对票，它列举了两个理由：

• 现有的语言已经能实现这类需求

• 具体来说，SQL/Property Graph Query 扩展以及 SQL 标准的其余部分可以满足需求

为什么我们需要一种特定于图形的查询语言？

许多供应商、研究人员和用户一致认为，可以使用非关系型“图形原生”存储和运行时模型来开发图形数据库。例如 Neo4j 的行业领先的图形数据库平台和新的 Redis Labs 图形产品。

但是，他们也需要一种类似 Cypher 的语言来支持数据的插入和维护，而不仅仅是数据查询。对于以图行为中心的语言来说，SQL 不太可能是一个合适的模型，所需的语言是能够将图形作为查询输入，然后输出一个图，就像 SQL 可以读取表，并生成实为新表的结果集。

GQL 和 SQL 如何协同工作？

许多支持 GQL 提案的公司和国家标准机构并不认为 GQL 和 SQL 是竞争对手，而是通过共享的基础和互操作来相互补充。(其中指的是核心数据类型和表达式的形成方式，以及共享的概念，如目录中持有的模式对象，以及与用户/角色相关的会话)。

SQL/PgQ 查询实际上是一个围绕着一段“proto-gql”的 SQL 子查询。下面有一个示例查询，在今年 SIGMOD 大会接近尾声时，Oracle 的Oskarvanrest 为今年 7 月在阿姆斯特丹举行的链接数据库基准理事会(Link Database Benchmark Council，LDBC)会议提出的。

以关键字 MATCH 开头的红色部分是模式匹配查询的一个片段，该查询非常类似用 Cypher 或 PGQL 编写的查询。你可能会注意到，它用于引入标签(如在 Creator IS Person 中)，以及用于引入主机参数或变量。但是，你也可以在标签表达式中使用冒号(如果 SQL 引擎的解析器是智能的)，那么与先前存在的“输入”属性图查询语言的相似性就会更加明显。

PgQ 查询的其他部分(黑色和绿色)将这个 Proto-GQL 连接到一个 SQL SELECT 语句中。表格结果通过 Columns 子句流到常规 SQL 查询中。它们只对与图形查询交互的 SQL 引擎来说是需要注意的，GQL 本身不会涉及到这种 SQL“外部函数接口”。

SQL 生成表，GQL 生成图

SQL 在一个关键方面与 Cypher 语言大不相同，Cypher 让用户在不知道将返回哪些类型的数据的情况下探索其数据图的结构。它可以让你进行真正的图形查询，其中值得注意不仅仅是值，还包括数据子集的形状，与匹配图模式的元素的值有关。换句话说，图查询针对在一个或多个输入图上计算的子图或投射图。

然而，SQL/PGQ、Cypher 和 PGQL 只允许你从图中提取一个表。这是必须保留的重要特性，因为否则就不可能获取存储在图元素上的实际数据值。但是将结果仅限于表意味着你无法轻松创建图转换链，也无法针对多个输入图执行集合操作。你也无法生成和存储快照图，无法定义图投射视图。

GQL 将建立在 openCypher Morpheus 的基础上(它将 Cypher 引入到 Apache Spark)，并结合来自 LDBC 的 G-CORE 的灵感，为用户提供了一种组合图查询语言，支持所有那些功能，这将使 GQL 在概念上等同于 SQL。

更普遍地说，GQL 是一种比 SQL 更现代的语言，它具有更结构化的类型系统。

GQL 项目的工作将于本月晚些时候在坦桑尼亚阿鲁沙召开的 SQL/GQL 标准委员会 ISO/IEC JTC 1 SC 32/WG3 的下一次会议上全面开始。

目前还无法确定 GQL 的第一个可实现版本，但很有可能在 2020 年下半年之前制定某个相当完整的草案。

来源：linkedin

本文素材来自互联网