建站
咨詢
售后
建站咨詢
新聞中心
?譯者 | 布加迪
審校 | 孫淑娟
GraphQL正迅速成為許多公司處理數(shù)據(jù)的首選查詢語(yǔ)言。雖然數(shù)據(jù)管理是許多公司最關(guān)心的問(wèn)題之一，但許多人并不真正了解GraphQL的作用或?yàn)楹稳绱舜笫軞g迎。
全世界每天平均生成約2.5萬(wàn)億字節(jié)的數(shù)據(jù)。企業(yè)需要一種方法來(lái)收集這些數(shù)據(jù)并有效地使用數(shù)據(jù)。大量數(shù)據(jù)在應(yīng)用程序中生成（比如客戶服務(wù)智能手機(jī)應(yīng)用程序讓客戶可以告訴您他們是否滿意，或者他們是否有任何問(wèn)題、需要幫助排除問(wèn)題）。應(yīng)用程序需要一種將信息發(fā)送到后端的方法，即管理和存儲(chǔ)數(shù)據(jù)的工具。然后可以分析數(shù)據(jù)，發(fā)現(xiàn)問(wèn)題、制定解決方案。當(dāng)然這是雙向的。應(yīng)用程序不僅將數(shù)據(jù)發(fā)送到后端，應(yīng)用程序也需要來(lái)自后端的數(shù)據(jù)，比如推薦、交貨狀態(tài)、賬戶余額。這正是GraphQL擅長(zhǎng)的：將數(shù)據(jù)發(fā)送到后端，并從后端獲取數(shù)據(jù)。它是一種更現(xiàn)代的API，可將應(yīng)用程序連接到后端。
雖然許多技術(shù)領(lǐng)導(dǎo)者可能聽(tīng)說(shuō)過(guò)GraphQL，但對(duì)SQL（結(jié)構(gòu)化查詢語(yǔ)言）可能更熟悉。SQL本質(zhì)上是數(shù)據(jù)庫(kù)查詢方面的行業(yè)標(biāo)準(zhǔn)，不過(guò)GraphQL的風(fēng)頭越來(lái)越勁。
GraphQL與SQL相比如何？有沒(méi)有辦法在執(zhí)行查詢時(shí)做到兩者的好處兼而得之？
1.GraphQL vs SQL：全面比較
GraphQL有比較簡(jiǎn)單、易讀的數(shù)據(jù)訪問(wèn)格式。這種獨(dú)特的格式允許所謂的“嵌套”（nesting）。嵌套好比在一個(gè)問(wèn)題中提出另一個(gè)問(wèn)題，以獲得更具體的答案。比如說(shuō)，您可能索要列出所有狗的列表以及這些狗各品種的嵌套詳細(xì)信息（從完全不同的數(shù)據(jù)源、甚至第三方數(shù)據(jù)源獲?。?，而不是僅僅索要列出某個(gè)棲息處的所有狗的列表。
QraphQL嵌套查詢的能力讓前端開(kāi)發(fā)人員可以通過(guò)一個(gè)請(qǐng)求從API獲取相關(guān)信息。由于GraphQL幾乎是一種通用查詢語(yǔ)言，可以輕松處理不同的數(shù)據(jù)源，您還能同時(shí)查詢多個(gè)API及其他數(shù)據(jù)源。因此GraphQL是適合異構(gòu)后端的查詢語(yǔ)言，這意味著除了數(shù)據(jù)庫(kù)外，后端還有不同類(lèi)型的數(shù)據(jù)源。
作為一種數(shù)據(jù)庫(kù)查詢語(yǔ)言，SQL非常流行。遺憾的是，它并不像 GraphQL 那樣適用于跨異構(gòu)數(shù)據(jù)的嵌套查詢。另外，SQL的語(yǔ)法可能很復(fù)雜。最后，SQL從未打算普遍通用。SQL適用于不同的數(shù)據(jù)庫(kù)，但不適用于API。
2.GraphQL與SQL的實(shí)際異同?
假設(shè)您在為公司的庫(kù)存補(bǔ)貨，需要知道從兩家不同公司發(fā)貨的兩筆不同訂單的跟蹤編號(hào)和預(yù)計(jì)交貨日期。GraphQL就能夠通過(guò)一個(gè)請(qǐng)求獲取所有這些信息。
GraphQL還以分層結(jié)構(gòu)向您顯示該信息，分層結(jié)構(gòu)使您可以輕松查看請(qǐng)求的數(shù)據(jù)之間的關(guān)系。換句話說(shuō)，您可以看到包裹的交付日期與收到的跟蹤編號(hào)相關(guān)聯(lián)。
如果是SQL，您可能需要向數(shù)據(jù)庫(kù)發(fā)出一個(gè)請(qǐng)求，以獲取有關(guān)兩筆不同訂單的一般信息。然后，您可能需要對(duì)該信息進(jìn)行分類(lèi)以查找發(fā)貨公司的名稱(chēng)，然后向每家發(fā)貨公司發(fā)出另一個(gè)請(qǐng)求，索要跟蹤編號(hào)。最后，根據(jù)跟蹤編號(hào)，您可能發(fā)出另一個(gè)請(qǐng)求，以獲取預(yù)期的交貨日期。獲取所有這些信息需要大量代碼，僅僅確保語(yǔ)法正確可能并非易事。幾十年來(lái)，本人一直與SQL數(shù)據(jù)庫(kù)打交道，連我都常常需要查詢復(fù)雜查詢的語(yǔ)法。
3.為什么SQL仍然如此流行？
GraphQL API模式僅允許一小部分操作，具體取決于實(shí)現(xiàn)該API的開(kāi)發(fā)人員。換句話說(shuō)，查詢的靈活性取決于API開(kāi)發(fā)人員的靈活性。比如說(shuō)，API只允許您通過(guò)電子郵件搜索客戶。要按城市搜索客戶，應(yīng)用程序就需要收集所有客戶，然后一一過(guò)濾。
或者如果您在處理敏感數(shù)據(jù)，可能需要針對(duì)多個(gè)因素來(lái)配置查詢和API：比如控制誰(shuí)可以訪問(wèn)數(shù)據(jù)，或數(shù)據(jù)在后端緩存（臨時(shí)保存）多久。這樣的配置對(duì)于普通公司來(lái)說(shuō)要求過(guò)高，但現(xiàn)在有許多技術(shù)可以為您管理和配置GraphQL查詢和API。這些技術(shù)使GraphQL成為了查詢API的可行選項(xiàng)，但如果沒(méi)有這些技術(shù)，配置可能很困難。
相比之下，SQL一開(kāi)始更具表達(dá)力，這意味著它可以更輕松地告訴系統(tǒng)您想要什么，無(wú)需進(jìn)行大量的額外配置。只需使用一行代碼，您可以輕松地查詢?nèi)魏螖?shù)據(jù)庫(kù)：“針對(duì)客戶 John Doe，請(qǐng)給我金額超過(guò)100美元的訂單”。無(wú)論數(shù)據(jù)庫(kù)結(jié)構(gòu)如何，SQL都會(huì)為您提供所需的數(shù)據(jù)。
GraphQL允許在構(gòu)建API的開(kāi)發(fā)人員設(shè)置的框架內(nèi)進(jìn)行靈活查詢，而SQL允許對(duì)任何數(shù)據(jù)庫(kù)模型進(jìn)行通用查詢。因此，如果您以查詢數(shù)據(jù)庫(kù)為主，SQL可以很好地完成工作。
4.有沒(méi)有辦法彌合鴻溝？?
如果可以同時(shí)利用SQL的表達(dá)性和GraphQL 的靈活性，那將會(huì)怎樣？市面上有一些技術(shù)聲稱(chēng)可以做到這一點(diǎn)，但它們不太可能變得流行起來(lái)，因?yàn)樗鼈冏罱K很笨拙很復(fù)雜。笨拙源于試圖將SQL構(gòu)件（construct）強(qiáng)行塞入到GraphQL中。但它們是兩種不同的查詢語(yǔ)言，用途不同。如果開(kāi)發(fā)人員必須學(xué)習(xí)如何在GraphQL中做SQL構(gòu)件，還不如使用SQL并直接連接到數(shù)據(jù)庫(kù)。
然而，還有一線生機(jī)。我們認(rèn)為，GraphQL會(huì)逐漸變得更具表達(dá)力。有一些方案旨在讓GraphQL更具表達(dá)力，這些方案最終可能會(huì)成為標(biāo)準(zhǔn)。但從根本上說(shuō)，SQL和GraphQL各自看待世界的視角不一樣：統(tǒng)一的后端vs多樣化的后端，表vs.分層數(shù)據(jù)，通用查詢vs.有限查詢。因此，它們用途各異。
盡管GraphQL 作為一種API查詢語(yǔ)言很受歡迎，但它不會(huì)取代SQL這種數(shù)據(jù)庫(kù)訪問(wèn)的主要語(yǔ)言。
原文鏈接：https://venturebeat.com/2022/08/04/graphql-is-a-big-deal-why-isnt-it-the-industry-standard-for-database-querying/?
文章名稱(chēng)：GraphQL為何不是數(shù)據(jù)庫(kù)查詢方面的行業(yè)標(biāo)準(zhǔn)？
當(dāng)前網(wǎng)址：http://www.5511xx.com/article/dhedges.html
