gql SQL 靠边站、GQL 来了：已成为 ISO/IEC 国际标准数据库语言项目图形

文章图片

属性图的标准查询语言
GQL是官方标准。今年6月，国际标准化组织/国际电工委员会联合技术委员会1所属的全球多个国家标准机构开始对GQL项目提案进行投票表决。投票于上周初结束，提案获得通过。七个国家派出专家执行这个为期四年的项目。

文章图片

【gql SQL 靠边站、GQL 来了：已成为 ISO/IEC 国际标准数据库语言项目】GQL的全称是“图形查询语言”。这种新语言将由监督SQL标准的同一个国际工作组开发和维护。GQL高度依赖现有语言。
主要是受Cypher、Oracle的PGQL和SQL本身的启发，以及新的用于只读属性图查询的SQL扩展。尽管Tigergraph的GSQL在风格上来自于与其他标准机构不同的起点，但它是另一个值得注意的贡献，其开发者已经对GQL项目表达了坚定的承诺。
SQL项目启动至今已有30多年，最初是ANSI标准:GQL是继SQL之后的第一个ISO/IEC国际标准数据库语言项目。十个国家投票支持这个新项目:中国、韩国、瑞典、美国、德国、英国、荷兰、丹麦、哈萨克斯坦、加拿大和芬兰。五个国家投了弃权票，因为它们缺乏判断或评论该提案的专业知识。
只有日本投了反对票。日本的评论很有意思。他们提出了两个原因:外部世界现有的语言达到了预期的效果；具体来说，SQL/属性映射查询扩展可以与SQL标准的其他部分一起满足需求。
我想谈谈为什么GQL的倡导者提出一种与SQL共存的新标准语言是正确的。
为什么我们需要一种专门针对图形的查询语言？
我在2018年5月提出了《GQL宣言》。这一举措的直接原因是:a)SQL/PGQ仅限于只读查询，b)它不能投影新图形，c)它只能基于生成的SQL表的图形视图访问图形。
然而，许多供应商、研究人员和用户一致认为，可以使用非关系的“图形原生”存储和运行时模型来开发图形数据库。他们绝对需要像Cypher这样的语言来支持数据插入和维护，而不仅仅是数据查询。然而，对于可以“基于图形生成”的以图形为中心的语言来说，SQL不太可能是一个合适的模型。基于图的生成是指获取图作为查询输入，从而输出图，就像SQL可以读取表并生成实际上是新表的结果集一样。
GQL和SQL是如何协同工作的？
很多支持GQL项目的公司和国家标准机构并不把GQL和SQL看作竞争对手，而是把它们看作可以通过共同的基础和互操作性进行互补的语言。所谓基础，我指的是核心数据类型、形成表达式的方法和通用概念
了解更多关于这两种语言如何协同工作的信息。
实际上，SQL/PGQ查询是一个用“proto-GQL”的一部分包装的SQL子查询。下面我演示的一个示例查询来自于关于SQL/PGQ的优秀数据；在今年的SIGMOD会议结束时，甲骨文的同事Oskar van Rest为7月在阿姆斯特丹举行的链接数据库基准委员会会议制作了这份材料。

文章图片

以关键字MATCH开头的红色部分是模式匹配查询的一个片段，它与用Cypher或PGQL编写的查询非常相似。您可能会注意到，IS用于引入标记，:用于引入主机参数或变量。但是，也可以在标签表达式中使用冒号，这将使与“Input”属性图的查询语言的相似性更加明显。
PGQ查询的其他部分将这个原型GQL合并到SQL SELECT语句中。表结果通过COLUMNS子句流向常规的SQL查询。它们只值得关注与图形查询交互的SQL引擎。GQL本身不会参与这个SQL“外函数接口”。