?譯者 | 布加迪

審校 | 孫淑娟

GraphQL正迅速成為許多公司處理數(shù)據(jù)的首選查詢語言。雖然數(shù)據(jù)管理是許多公司最關(guān)心的問題之一，但許多人并不真正了解GraphQL的作用或?yàn)楹稳绱舜笫軞g迎。

全世界每天平均生成約2.5萬億字節(jié)的數(shù)據(jù)。企業(yè)需要一種方法來收集這些數(shù)據(jù)并有效地使用數(shù)據(jù)。大量數(shù)據(jù)在應(yīng)用程序中生成（比如客戶服務(wù)智能手機(jī)應(yīng)用程序讓客戶可以告訴您他們是否滿意，或者他們是否有任何問題、需要幫助排除問題）。應(yīng)用程序需要一種將信息發(fā)送到后端的方法，即管理和存儲(chǔ)數(shù)據(jù)的工具。然后可以分析數(shù)據(jù)，發(fā)現(xiàn)問題、制定解決方案。當(dāng)然這是雙向的。應(yīng)用程序不僅將數(shù)據(jù)發(fā)送到后端，應(yīng)用程序也需要來自后端的數(shù)據(jù)，比如推薦、交貨狀態(tài)、賬戶余額。這正是GraphQL擅長的：將數(shù)據(jù)發(fā)送到后端，并從后端獲取數(shù)據(jù)。它是一種更現(xiàn)代的API，可將應(yīng)用程序連接到后端。

雖然許多技術(shù)領(lǐng)導(dǎo)者可能聽說過GraphQL，但對(duì)SQL（結(jié)構(gòu)化查詢語言）可能更熟悉。SQL本質(zhì)上是數(shù)據(jù)庫查詢方面的行業(yè)標(biāo)準(zhǔn)，不過GraphQL的風(fēng)頭越來越勁。

GraphQL與SQL相比如何？有沒有辦法在執(zhí)行查詢時(shí)做到兩者的好處兼而得之？

1.GraphQL vs SQL：全面比較

GraphQL有比較簡單、易讀的數(shù)據(jù)訪問格式。這種獨(dú)特的格式允許所謂的“嵌套”（nesting）。嵌套好比在一個(gè)問題中提出另一個(gè)問題，以獲得更具體的答案。比如說，您可能索要列出所有狗的列表以及這些狗各品種的嵌套詳細(xì)信息（從完全不同的數(shù)據(jù)源、甚至第三方數(shù)據(jù)源獲?。?，而不是僅僅索要列出某個(gè)棲息處的所有狗的列表。

QraphQL嵌套查詢的能力讓前端開發(fā)人員可以通過一個(gè)請(qǐng)求從API獲取相關(guān)信息。由于GraphQL幾乎是一種通用查詢語言，可以輕松處理不同的數(shù)據(jù)源，您還能同時(shí)查詢多個(gè)API及其他數(shù)據(jù)源。因此GraphQL是適合異構(gòu)后端的查詢語言，這意味著除了數(shù)據(jù)庫外，后端還有不同類型的數(shù)據(jù)源。

作為一種數(shù)據(jù)庫查詢語言，SQL非常流行。遺憾的是，它并不像 GraphQL 那樣適用于跨異構(gòu)數(shù)據(jù)的嵌套查詢。另外，SQL的語法可能很復(fù)雜。最后，SQL從未打算普遍通用。SQL適用于不同的數(shù)據(jù)庫，但不適用于API。

2.GraphQL與SQL的實(shí)際異同?

假設(shè)您在為公司的庫存補(bǔ)貨，需要知道從兩家不同公司發(fā)貨的兩筆不同訂單的跟蹤編號(hào)和預(yù)計(jì)交貨日期。GraphQL就能夠通過一個(gè)請(qǐng)求獲取所有這些信息。

GraphQL還以分層結(jié)構(gòu)向您顯示該信息，分層結(jié)構(gòu)使您可以輕松查看請(qǐng)求的數(shù)據(jù)之間的關(guān)系。換句話說，您可以看到包裹的交付日期與收到的跟蹤編號(hào)相關(guān)聯(lián)。

如果是SQL，您可能需要向數(shù)據(jù)庫發(fā)出一個(gè)請(qǐng)求，以獲取有關(guān)兩筆不同訂單的一般信息。然后，您可能需要對(duì)該信息進(jìn)行分類以查找發(fā)貨公司的名稱，然后向每家發(fā)貨公司發(fā)出另一個(gè)請(qǐng)求，索要跟蹤編號(hào)。最后，根據(jù)跟蹤編號(hào)，您可能發(fā)出另一個(gè)請(qǐng)求，以獲取預(yù)期的交貨日期。獲取所有這些信息需要大量代碼，僅僅確保語法正確可能并非易事。幾十年來，本人一直與SQL數(shù)據(jù)庫打交道，連我都常常需要查詢復(fù)雜查詢的語法。

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

GraphQL API模式僅允許一小部分操作，具體取決于實(shí)現(xiàn)該API的開發(fā)人員。換句話說，查詢的靈活性取決于API開發(fā)人員的靈活性。比如說，API只允許您通過電子郵件搜索客戶。要按城市搜索客戶，應(yīng)用程序就需要收集所有客戶，然后一一過濾。

或者如果您在處理敏感數(shù)據(jù)，可能需要針對(duì)多個(gè)因素來配置查詢和API：比如控制誰可以訪問數(shù)據(jù)，或數(shù)據(jù)在后端緩存（臨時(shí)保存）多久。這樣的配置對(duì)于普通公司來說要求過高，但現(xiàn)在有許多技術(shù)可以為您管理和配置GraphQL查詢和API。這些技術(shù)使GraphQL成為了查詢API的可行選項(xiàng)，但如果沒有這些技術(shù)，配置可能很困難。

相比之下，SQL一開始更具表達(dá)力，這意味著它可以更輕松地告訴系統(tǒng)您想要什么，無需進(jìn)行大量的額外配置。只需使用一行代碼，您可以輕松地查詢?nèi)魏螖?shù)據(jù)庫：“針對(duì)客戶 John Doe，請(qǐng)給我金額超過100美元的訂單”。無論數(shù)據(jù)庫結(jié)構(gòu)如何，SQL都會(huì)為您提供所需的數(shù)據(jù)。

GraphQL允許在構(gòu)建API的開發(fā)人員設(shè)置的框架內(nèi)進(jìn)行靈活查詢，而SQL允許對(duì)任何數(shù)據(jù)庫模型進(jìn)行通用查詢。因此，如果您以查詢數(shù)據(jù)庫為主，SQL可以很好地完成工作。

4.有沒有辦法彌合鴻溝？?

如果可以同時(shí)利用SQL的表達(dá)性和GraphQL 的靈活性，那將會(huì)怎樣？市面上有一些技術(shù)聲稱可以做到這一點(diǎn)，但它們不太可能變得流行起來，因?yàn)樗鼈冏罱K很笨拙很復(fù)雜。笨拙源于試圖將SQL構(gòu)件（construct）強(qiáng)行塞入到GraphQL中。但它們是兩種不同的查詢語言，用途不同。如果開發(fā)人員必須學(xué)習(xí)如何在GraphQL中做SQL構(gòu)件，還不如使用SQL并直接連接到數(shù)據(jù)庫。

然而，還有一線生機(jī)。我們認(rèn)為，GraphQL會(huì)逐漸變得更具表達(dá)力。有一些方案旨在讓GraphQL更具表達(dá)力，這些方案最終可能會(huì)成為標(biāo)準(zhǔn)。但從根本上說，SQL和GraphQL各自看待世界的視角不一樣：統(tǒng)一的后端vs多樣化的后端，表vs.分層數(shù)據(jù)，通用查詢vs.有限查詢。因此，它們用途各異。

盡管GraphQL 作為一種API查詢語言很受歡迎，但它不會(huì)取代SQL這種數(shù)據(jù)庫訪問的主要語言。

原文鏈接：https://venturebeat.com/2022/08/04/graphql-is-a-big-deal-why-isnt-it-the-industry-standard-for-database-querying/?