GraphQL为何不是数据库查询方面的行业标准？

GraphQL为何不是数据库查询方面的行业标准？

​译者 | 布加迪

审校 | 孙淑娟

GraphQL正迅速成为许多公司处理数据的首选查询语言。虽然数据管理是许多公司最关心的问题之一，但许多人并不真正了解GraphQL的作用或为何如此大受欢迎。

全世界每天平均生成约2.5万亿字节的数据。企业需要一种方法来收集这些数据并有效地使用数据。大量数据在应用程序中生成（比如客户服务智能手机应用程序让客户可以告诉您他们是否满意，或者他们是否有任何问题、需要帮助排除问题）。应用程序需要一种将信息发送到后端的方法，即管理和存储数据的工具。然后可以分析数据，发现问题、制定解决方案。当然这是双向的。应用程序不仅将数据发送到后端，应用程序也需要来自后端的数据，比如推荐、交货状态、账户余额。这正是GraphQL擅长的：将数据发送到后端，并从后端获取数据。它是一种更现代的API，可将应用程序连接到后端。

虽然许多技术领导者可能听说过GraphQL，但对SQL（结构化查询语言）可能更熟悉。SQL本质上是数据库查询方面的行业标准，不过GraphQL的风头越来越劲。

GraphQL与SQL相比如何？有没有办法在执行查询时做到两者的好处兼而得之？

1.GraphQL vs SQL：全面比较

GraphQL有比较简单、易读的数据访问格式。这种独特的格式允许所谓的“嵌套”（nesting）。嵌套好比在一个问题中提出另一个问题，以获得更具体的答案。比如说，您可能索要列出所有狗的列表以及这些狗各品种的嵌套详细信息（从完全不同的数据源、甚至第三方数据源获取），而不是仅仅索要列出某个栖息处的所有狗的列表。

QraphQL嵌套查询的能力让前端开发人员可以通过一个请求从API获取相关信息。由于GraphQL几乎是一种通用查询语言，可以轻松处理不同的数据源，您还能同时查询多个API及其他数据源。因此GraphQL是适合异构后端的查询语言，这意味着除了数据库外，后端还有不同类型的数据源。

作为一种数据库查询语言，SQL非常流行。遗憾的是，它并不像 GraphQL 那样适用于跨异构数据的嵌套查询。另外，SQL的语法可能很复杂。最后，SQL从未打算普遍通用。SQL适用于不同的数据库，但不适用于API。

2.GraphQL与SQL的实际异同​

假设您在为公司的库存补货，需要知道从两家不同公司发货的两笔不同订单的跟踪编号和预计交货日期。GraphQL就能够通过一个请求获取所有这些信息。

GraphQL还以分层结构向您显示该信息，分层结构使您可以轻松查看请求的数据之间的关系。换句话说，您可以看到包裹的交付日期与收到的跟踪编号相关联。

如果是SQL，您可能需要向数据库发出一个请求，以获取有关两笔不同订单的一般信息。然后，您可能需要对该信息进行分类以查找发货公司的名称，然后向每家发货公司发出另一个请求，索要跟踪编号。最后，根据跟踪编号，您可能发出另一个请求，以获取预期的交货日期。获取所有这些信息需要大量代码，仅仅确保语法正确可能并非易事。几十年来，本人一直与SQL数据库打交道，连我都常常需要查询复杂查询的语法。

3.为什么SQL仍然如此流行？

GraphQL API模式仅允许一小部分操作，具体取决于实现该API的开发人员。换句话说，查询的灵活性取决于API开发人员的灵活性。比如说，API只允许您通过电子邮件搜索客户。要按城市搜索客户，应用程序就需要收集所有客户，然后一一过滤。

或者如果您在处理敏感数据，可能需要针对多个因素来配置查询和API：比如控制谁可以访问数据，或数据在后端缓存（临时保存）多久。这样的配置对于普通公司来说要求过高，但现在有许多技术可以为您管理和配置GraphQL查询和API。这些技术使GraphQL成为了查询API的可行选项，但如果没有这些技术，配置可能很困难。

相比之下，SQL一开始更具表达力，这意味着它可以更轻松地告诉系统您想要什么，无需进行大量的额外配置。只需使用一行代码，您可以轻松地查询任何数据库：“针对客户 John Doe，请给我金额超过100美元的订单”。无论数据库结构如何，SQL都会为您提供所需的数据。

GraphQL允许在构建API的开发人员设置的框架内进行灵活查询，而SQL允许对任何数据库模型进行通用查询。因此，如果您以查询数据库为主，SQL可以很好地完成工作。

4.有没有办法弥合鸿沟？​

如果可以同时利用SQL的表达性和GraphQL 的灵活性，那将会怎样？市面上有一些技术声称可以做到这一点，但它们不太可能变得流行起来，因为它们最终很笨拙很复杂。笨拙源于试图将SQL构件（construct）强行塞入到GraphQL中。但它们是两种不同的查询语言，用途不同。如果开发人员必须学习如何在GraphQL中做SQL构件，还不如使用SQL并直接连接到数据库。

然而，还有一线生机。我们认为，GraphQL会逐渐变得更具表达力。有一些方案旨在让GraphQL更具表达力，这些方案最终可能会成为标准。但从根本上说，SQL和GraphQL各自看待世界的视角不一样：统一的后端vs多样化的后端，表vs.分层数据，通用查询vs.有限查询。因此，它们用途各异。

尽管GraphQL 作为一种API查询语言很受欢迎，但它不会取代SQL这种数据库访问的主要语言。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。