क्या सुविधा फ्रीज 2019 पर जमी थी। भाग I JSONPath

2019-03 समितियों के बाद, सुविधा फ्रीज हुई। हमारे यहां लगभग एक पारंपरिक कॉलम है: हमने पहले ही पिछले साल के फ्रीज के बारे में लिखा था । अब, 2019 के परिणाम: कौन से नए को PostgreSQL 12. में शामिल किया जाएगा, JSONPath को समर्पित समीक्षा के इस भाग में, "पोस्टग्रूज 12 इन एट्र्यूड्स" रिपोर्ट से उदाहरण और टुकड़े, जो कि ओलेग बार्टुनोव ने सेंट पीटर्सबर्ग में सेंट हाइलोड ++ में इस साल 9 अप्रैल को पढ़ा है, का उपयोग किया जाता है।

JSONPath

JSON (B) से संबंधित सब कुछ प्रासंगिक है, दुनिया में, रूस में मांग में, और यह Postgres Professional में विकास के सबसे महत्वपूर्ण क्षेत्रों में से एक है। JSON / JSONB के साथ काम करने के लिए jsonb प्रकार, फ़ंक्शंस और ऑपरेटर PostgreSQL संस्करण 9.4 में दिखाई दिए, वे ओलेग बार्टुनोव के नेतृत्व में एक टीम द्वारा किए गए थे।

JSON के साथ काम करने के लिए SQL / 2016 मानक प्रदान करता है: JSONPath का उल्लेख वहां किया गया है - JSON के अंदर डेटा एड्रेसिंग टूल का एक सेट; JSONTABLE - JSON को नियमित तालिकाओं में परिवर्तित करने का साधन; कार्यों और ऑपरेटरों का एक बड़ा परिवार। इस तथ्य के बावजूद कि पोस्टसन में जेन्सन को लंबे समय से समर्थन दिया गया है, 2017 में ओलेग बार्टुनोव और उनके सहयोगियों ने मानक का समर्थन करने पर काम करना शुरू कर दिया। मानक के साथ अनुपालन हमेशा अच्छा होता है। मानक में वर्णित सभी में से, केवल एक लेकिन सबसे महत्वपूर्ण पैच 12 संस्करण में JSONPath है, इसलिए हम इसके बारे में पहले स्थान पर बात करेंगे।

प्राचीन समय में, लोग JSON का उपयोग करते थे, इसे पाठ क्षेत्रों में संग्रहीत करते थे। 9.3 में, JSON के लिए एक विशेष डेटा प्रकार दिखाई दिया, लेकिन इसके साथ जुड़ी कार्यक्षमता समृद्ध नहीं थी, और इस प्रकार के साथ अनुरोधों ने JSON के पाठ प्रतिनिधित्व को पार्स करने में लगने वाले समय के कारण धीरे-धीरे काम किया। इसने कई संभावित पोस्टग्रेज यूजर्स को रोक दिया, जिन्होंने NoSQL डेटाबेस को प्राथमिकता दी। O. बार्टुनोव, ए। कोरोटकोव और एफ। सिगेव की बदौलत पोस्टग्रैज उत्पादकता में 9.4 की वृद्धि हुई, पोस्टग्रेज ने JSON - बाइसन प्रकार का बाइनरी संस्करण पेश किया।
jsonb को हर बार पार्स करने की आवश्यकता नहीं होती है, इसलिए इसके साथ काम करना ज्यादा तेज होता है। एक ही समय में उत्पन्न होने वाले नए कार्यों और ऑपरेटरों में से, कुछ केवल एक नए, द्विआधारी प्रकार के साथ काम करते हैं, जैसे कि घटना के महत्वपूर्ण ऑपरेटर @> , जो यह जांचता है कि क्या दिए गए JSONB में एक तत्व या सरणी शामिल है:

SELECT '[1, 2, 3]'::jsonb @> '[1, 3]'::jsonb; 

TRUE देता है, क्योंकि दाईं ओर स्थित सरणी बाईं ओर स्थित सरणी में प्रवेश करती है। लेकिन

 SELECT '[1, 2, [1, 3]]'::jsonb @> '[1, 3]'::jsonb; 

FALSE देगा, क्योंकि घोंसले के शिकार का स्तर अलग है, इसे स्पष्ट रूप से सेट किया जाना चाहिए। क्या अस्तित्व ऑपरेटर को टाइपसन के लिए पेश किया गया है ? (एक प्रश्न चिह्न) जो यह जांचता है कि क्या JSONB मूल्यों के शीर्ष स्तर पर एक स्ट्रिंग एक ऑब्जेक्ट कुंजी या किसी सरणी का एक तत्व है, साथ ही दो और समान ऑपरेटर ( यहां विवरण)। वे GIN ऑपरेटरों के दो वर्गों के साथ GIN अनुक्रमित द्वारा समर्थित हैं। ऑपरेटर -> (तीर) आपको JSONB के माध्यम से "नेविगेट" करने की अनुमति देता है, यह कुंजी द्वारा या अगर यह एक सरणी है, तो सूचकांक द्वारा एक मान लौटाता है। स्थानांतरित करने के लिए कई और ऑपरेटर हैं। लेकिन फ़िल्टर को व्यवस्थित करने का कोई तरीका नहीं है जो WHERE की तरह काम करता है। यह एक सफलता थी: jsonb के लिए धन्यवाद, Postgres RDSQL के रूप में NoSQL सुविधाओं के साथ लोकप्रियता में बढ़ने लगे।

2014 में, ए। कोरोटकोव, ओ। बार्टुनोव और एफ। सिगेव ने jsquery एक्सटेंशन विकसित किया, जिसे पोस्टग्रेज प्रो स्टैंडर्ड 9.5 (और स्टैंडर्ड और एंटरप्राइज के बाद के संस्करणों में) के परिणामस्वरूप शामिल किया गया था। यह json (b) के साथ काम करने के लिए अतिरिक्त, बहुत व्यापक सुविधाएँ प्रदान करता है। यह एक्सटेंशन इन प्रश्नों को गति देने के लिए json (b) और इंडेक्स से डेटा निकालने के लिए क्वेरी भाषा को परिभाषित करता है। उपयोगकर्ताओं द्वारा इस कार्यक्षमता की आवश्यकता थी, वे वेनिला संस्करण में मानक और नई सुविधाओं को शामिल करने के लिए इंतजार करने के लिए तैयार नहीं थे। व्यावहारिक मूल्य इस तथ्य से भी स्पष्ट है कि विकास Wargaming.net द्वारा प्रायोजित किया गया था। विस्तार एक विशेष प्रकार - jsquery को लागू करता है।

इस भाषा में एक प्रश्न कॉम्पैक्ट है और उदाहरण के लिए, इस तरह दिखता है:

 SELECT '{"apt":[{"no": 1, "rooms":2}, {"no": 2, "rooms":3}, {"no": 3, "rooms":2}]}'::jsonb @@ 'apt.#.rooms=3'::jsquery; 

हम यहां पूछ रहे हैं कि क्या अपार्टमेंट बिल्डिंग में "तीन रूबल" हैं। Jsquery प्रकार को निर्दिष्ट किया जाना चाहिए क्योंकि @@ ऑपरेटर अब jsonb प्रकार में भी है। वर्णन यहाँ है , और कई उदाहरणों के साथ प्रस्तुति यहाँ है ।

कुल: Postgres में JSON के साथ काम करने के लिए पहले से ही सब कुछ था, और फिर SQL: 2016 मानक दिखाई दिया। यह पता चला कि इसके शब्दार्थ हमारे jsquery के विस्तार से अलग नहीं हैं। यह संभव है कि मानक के लेखकों ने भी jsquery पर नज़र डाली, JSONPath का आविष्कार किया। हमारी टीम को थोड़ा अलग तरीके से लागू करना था जो हमारे पास पहले से था और निश्चित रूप से, बहुत सारी नई चीजें भी।

एक वर्ष से भी अधिक समय पहले, मार्च में, हमारे प्रोग्रामिंग प्रयासों का फल एसक्यूएल के लिए समर्थन के साथ 3 बड़े पैच के रूप में समुदाय को पेश किया गया था : 2016 मानक:

SQL / JSON: JSONPath;
SQL / JSON: फ़ंक्शन;
SQL / JSON: JSON_TABLE।

लेकिन एक पैच विकसित करना संपूर्ण व्यवसाय नहीं है, उन्हें बढ़ावा देना भी आसान नहीं है, खासकर यदि पैच बड़े हैं और कई मॉड्यूलों को प्रभावित करते हैं। संशोधन संशोधन के कई पुनरावृत्तियों की आवश्यकता होती है, पैच को बढ़ावा दिया जाना चाहिए, जैसा कि वाणिज्यिक कंपनियां करती हैं, बहुत सारे संसाधनों (मानव-घंटे) का निवेश करती हैं। पोस्टग्रेज प्रोफेशनल, अलेक्जेंडर कोरोटकोव के मुख्य वास्तुकार, ने इसे खुद पर ले लिया (क्योंकि अब उन्हें कमिटेटर का दर्जा मिला है) और पैच की इस श्रृंखला में मुख्य JSONPath पैच को अपनाना सुरक्षित है। दूसरा और तीसरा अब नीड्स रिव्यू की स्थिति में हैं। केंद्रित JSONPath आपको JSON (B) संरचना के साथ काम करने की अनुमति देता है और इसके टुकड़ों को उजागर करने के लिए पर्याप्त लचीला है। मानक में निर्धारित 15 बिंदुओं में से 14 को लागू किया गया है, और यह ओरेकल, MySQL और MS SQL में अधिक है।

JSONPath संकेतन JSON और JSQuery संकेतन के साथ काम करने के लिए पोस्टग्रैज स्टेटमेंट से अलग है। पदानुक्रम को बिंदुओं द्वारा दर्शाया गया है:

$ .abc (11 संकेतन के बाद, मुझे 'a' -> 'b' -> 'c') लिखना होगा;
$ - तत्व का वर्तमान संदर्भ - वास्तव में, $ के साथ अभिव्यक्ति json (बी) क्षेत्र को परिभाषित करता है जिसे संसाधित किया जाना है, जिसमें फ़िल्टर में एक भी शामिल है, बाकी यह काम के लिए उपलब्ध नहीं है;
@ - फ़िल्टर अभिव्यक्ति में वर्तमान संदर्भ - $ के साथ अभिव्यक्ति में उपलब्ध पथों पर पुनरावृत्त करता है;
[*] - एक सरणी;
* - वाइल्डकार्ड, $ या @ के साथ अभिव्यक्ति में पथ खंड के किसी भी मूल्य का मतलब है, लेकिन पदानुक्रम को ध्यान में रखते हुए;
** - $ या @ के साथ अभिव्यक्ति के हिस्से का मतलब पदानुक्रम को ध्यान में रखे बिना पथ खंड के किसी भी मूल्य से हो सकता है - यदि आप तत्वों के घोंसले के शिकार के स्तर को नहीं जानते हैं, तो इसका उपयोग करना सुविधाजनक है;
ऑपरेटर "?" आपको WHERE के समान एक फ़िल्टर व्यवस्थित करने की अनुमति देता है:
$ .abc? (@ .x> 10);
$ .abcxtype (), साथ ही आकार (), डबल (), छत (), फर्श (), abs (), डेटाटाइम (), कीवल्यू () विधियां हैं।
Jsonb_path_query फ़ंक्शन (नीचे फ़ंक्शन के बारे में) के साथ एक क्वेरी इस तरह दिख सकती है:

 SELECT jsonb_path_query_array('[1,2,3,4,5]', '$[*] ? (@ > 3)'); jsonb_path_query_array ------------------------ [4, 5] (1 row) 

हालांकि फ़ंक्शन के साथ एक विशेष पैच शुरू नहीं हुआ है, JSONPath पैच में पहले से ही JSON (B) के साथ काम करने के लिए प्रमुख कार्य हैं:

 jsonb_path_exists('{"a": 1}', '$.a')  true (  "?") jsonb_path_exists('{"a": 1}', '$.b')  false jsonb_path_match('{"a": 1}', '$.a == 1')  true (  "@>") jsonb_path_match('{"a": 1}', '$.a >= 2')  false jsonb_path_query('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 2)')  3, 4, 5 jsonb_path_query('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 5)')  0  jsonb_path_query_array('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 2)')  [3, 4, 5] jsonb_path_query_array('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 5)')  [] jsonb_path_query_first('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 2)')  3 jsonb_path_query_first('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 5)')  NULL 

ध्यान दें कि JSONPath अभिव्यक्तियों में समानता एकल "=" है, जबकि jsquery में यह डबल है: "=="।

अधिक सुरुचिपूर्ण चित्रों के लिए, हम JSONB को एकल-स्तंभ हाउस प्लेट में उत्पन्न करेंगे:

 CREATE TABLE house(js jsonb); INSERT INTO house VALUES ('{ "address": { "city":"Moscow", "street": "Ulyanova, 7A" }, "lift": false, "floor": [ { "level": 1, "apt": [ {"no": 1, "area": 40, "rooms": 1}, {"no": 2, "area": 80, "rooms": 3}, {"no": 3, "area": 50, "rooms": 2} ] }, { "level": 2, "apt": [ {"no": 4, "area": 100, "rooms": 3}, {"no": 5, "area": 60, "rooms": 2} ] } ] }'); 

अंजीर। 1 आवंटित पत्ती अपार्टमेंट के साथ आवास JSON पेड़।

यह एक अजीब JSON है: इसमें एक भ्रमित पदानुक्रम है, लेकिन इसे जीवन से लिया जाता है, और जीवन में अक्सर यह आवश्यक है कि क्या होना चाहिए, और क्या नहीं होना चाहिए। नए संस्करण की क्षमताओं के साथ, हम पहली और दूसरी मंजिल पर अपार्टमेंट पाएंगे, लेकिन फर्श अपार्टमेंट की सूची में पहले नहीं (जिस पेड़ पर वे हरे रंग में हाइलाइट किए गए हैं):

 SELECT jsonb_path_query_array(js, '$.floor[0, 1].apt[1 to last]') FROM house; --------------------- [{"no": 2, "area": 80, "rooms": 3}, {"no": 3, "area": 50, "rooms": 2}, {"no": 5, "area": 60, "rooms": 2}] 

PostgreSQL 11 में, आपको यह पूछना होगा:

 SELECT jsonb_agg(apt) FROM ( SELECT apt->generate_series(1, jsonb_array_length(apt) - 1) FROM ( SELECT js->'floor'->unnest(array[0, 1])->'apt' FROM house ) apts(apt) ) apts(apt); 

अब एक बहुत ही सरल प्रश्न: क्या वहाँ (कहीं भी) "मास्को" मूल्य वाली लाइनें हैं? वास्तव में सरल:

 SELECT jsonb_path_exists(js, '$.** ? (@ == "Moscow")') FROM house; 

संस्करण 11 में, आपको एक विशाल स्क्रिप्ट लिखनी होगी:

 WITH RECURSIVE t(value) AS ( SELECT * FROM house UNION ALL ( SELECT COALESCE(kv.value, e.value) AS value FROM t LEFT JOIN LATERAL jsonb_each ( CASE WHEN jsonb_typeof(t.value) = 'object' THEN t.value ELSE NULL END ) kv ON true LEFT JOIN LATERAL jsonb_array_elements ( CASE WHEN jsonb_typeof(t.value) = 'array' THEN t.value ELSE NULL END ) e ON true WHERE kv.value IS NOT NULL OR e.value IS NOT NULL ) ) SELECT EXISTS (SELECT 1 FROM t WHERE value = '"Moscow"'); 

अंजीर। 2 हाउसिंग JSON, मास्को का पेड़ पाया गया!

हम 40 से 90 वर्गमीटर के क्षेत्र के साथ किसी भी मंजिल पर किसी भी अपार्टमेंट की तलाश कर रहे हैं:

 select jsonb_path_query(js, '$.floor[*].apt[*] ? (@.area > 40 && @.area < 90)') FROM house; jsonb_path_query ----------------------------------- {"no": 2, "area": 80, "rooms": 3} {"no": 3, "area": 50, "rooms": 2} {"no": 5, "area": 60, "rooms": 2} (3 rows) 

हम 3 के बाद के कमरे के साथ अपार्टमेंट की तलाश कर रहे हैं, हमारे आवास जेसन का उपयोग कर:

 SELECT jsonb_path_query(js, '$.floor.apt.no ? (@>3)') FROM house; jsonb_path_query ------------------ 4 5 (2 rows) 

और यहाँ है कि कैसे jsonb_path_query_first काम करता है:

 SELECT jsonb_path_query_first(js, '$.floor.apt.no ? (@>3)') FROM house; jsonb_path_query_first ------------------------ 4 (1 row) 

हम देखते हैं कि केवल पहला मान चुना गया है जो फ़िल्टर स्थिति को संतुष्ट करता है।

JSONB @@ के लिए बूलियन JSONPath ऑपरेटर को मिलान ऑपरेटर कहा जाता है। यह JSONb_path_match_opr फ़ंक्शन को कॉल करके JSONPath की गणना करता है।

एक और बूलियन ऑपरेटर है @? - यह अस्तित्व की एक परीक्षा है, इस सवाल का जवाब देता है कि क्या JSONPath अभिव्यक्ति SQL / JSON ऑब्जेक्ट लौटाएगा, इसे jsonb_path_exists_opr फ़ंक्शन कहते हैं:

  '[1,2,3]' @@ '$[*] == 3'  true;  '[1,2,3]' @? '$[*] @? (@ == 3)' -  true 

एक ही परिणाम विभिन्न ऑपरेटरों का उपयोग करके प्राप्त किया जा सकता है:

 js @? '$.a'  js @@ 'exists($.a)' js @@ '$.a == 1'  js @? '$ ? ($.a == 1)' 

JSONPath बूलियन ऑपरेटरों की सुंदरता यह है कि वे GIN सूचकांकों द्वारा त्वरित, समर्थित हैं। jsonb_ops और jsonb_path_ops संबंधित ऑपरेटर वर्ग हैं। उदाहरण में, हम SEQSCAN को अक्षम कर देते हैं, क्योंकि हमारे पास एक माइक्रोएबिलिटी है, बड़े टेबलों पर ऑप्टिमाइज़र खुद बिटमैप इंडेक्स का चयन करेगा:

 SET ENABLE_SEQSCAN TO OFF; CREATE INDEX ON house USING gin (js); EXPLAIN (COSTS OFF) SELECT * FROM house WHERE js @? '$.floor[*].apt[*] ? (@.rooms == 3)'; QUERY PLAN -------------------------------------------------------------------------------- Bitmap Heap Scan on house Recheck Cond: (js @? '$."floor"[*]."apt"[*]?(@."rooms" == 3)'::jsonpath) -> Bitmap Index Scan on house_js_idx Index Cond: (js @? '$."floor"[*]."apt"[*]?(@."rooms" == 3)'::jsonpath) (4 rows) 

फॉर्म के सभी कार्य jsonb_path_xxx () में एक ही हस्ताक्षर हैं:

 jsonb_path_xxx( js jsonb, jsp jsonpath, vars jsonb DEFAULT '{}', silent boolean DEFAULT false ) 

vars JSONPath चर को पास करने के लिए JSONB ऑब्जेक्ट है:

 SELECT jsonb_path_query_array('[1,2,3,4,5]', '$[*] ? (@ > $x)', vars => '{"x": 2}'); jsonb_path_query_array ------------------------ [3, 4, 5] 

जब हम एक टेबल में से एक में एक जोंसब प्रकार के क्षेत्र को शामिल करते हैं, तो बिना var के करना मुश्किल है। मान लें कि हम एक ऐसा आवेदन करते हैं जो उस घर के कर्मचारियों के लिए उपयुक्त अपार्टमेंट की तलाश करता है जिन्होंने प्रश्नावली में न्यूनतम क्षेत्र के लिए अपनी आवश्यकताओं को लिखा है:

 CREATE TABLE demands(name text, position text, demand int); INSERT INTO demands VALUES ('','', 85), ('',' ', 45); SELECT jsonb_path_query(js, '$.floor[*].apt[*] ? (@.area >= $min)', vars => jsonb_build_object('min', demands.demand)) FROM house, demands WHERE name = ''; -[ RECORD 1 ]----+----------------------------------- jsonb_path_query | {"no": 2, "area": 80, "rooms": 3} -[ RECORD 2 ]----+----------------------------------- jsonb_path_query | {"no": 3, "area": 50, "rooms": 2} -[ RECORD 3 ]----+----------------------------------- jsonb_path_query | {"no": 4, "area": 100, "rooms": 3} -[ RECORD 4 ]----+----------------------------------- jsonb_path_query | {"no": 5, "area": 60, "rooms": 2} 

लकी पाशा 4 अपार्टमेंट में से चुन सकता है। लेकिन यह अनुरोध में 1 अक्षर को बदलने के लायक है - "पी" से "सी" तक, और कोई विकल्प नहीं होगा! केवल 1 अपार्टमेंट करेगा।


एक और खोजशब्द बना हुआ है: मौन एक ध्वज है जो त्रुटि से निपटने को दबाता है, वे प्रोग्रामर के विवेक पर हैं।

 SELECT jsonb_path_query('[]', 'strict $.a'); ERROR: SQL/JSON member not found DETAIL: jsonpath member accessor can only be applied to an object 

त्रुटि। लेकिन यह एक त्रुटि नहीं होगी:

 SELECT jsonb_path_query('[]', 'strict $.a', silent => true); jsonb_path_query ------------------ (0 rows) 

वैसे, त्रुटियों के बारे में: मानक के अनुसार, अभिव्यक्तियों में अंकगणितीय त्रुटियां त्रुटि संदेश नहीं देती हैं, वे प्रोग्रामर के विवेक पर हैं:

 SELECT jsonb_path_query('[1,0,2]', '$[*] ? (1/ @ >= 1)'); jsonb_path_query ------------------ 1 (1 row) 

फ़िल्टर में अभिव्यक्ति की गणना करते समय, सरणी मान खोजे जाते हैं, जिनके बीच 0 होते हैं, लेकिन 0 से विभाजित करने से कोई त्रुटि उत्पन्न नहीं होती है।

चयनित मोड के आधार पर फ़ंक्शंस अलग तरीके से काम करेंगे: सख्त या लाल (अनुवाद में "गैर-सख्त" या "ढीला", यह डिफ़ॉल्ट रूप से चुना गया है)। मान लीजिए कि हम JSON में लैक मोड में एक कुंजी की तलाश कर रहे हैं, जहां यह स्पष्ट रूप से नहीं है:

 SELECT jsonb '{"a":1}' @? 'lax $.b ? (@ > 1)'; ?column? ---------- f (1 row) 

अब स्ट्रिक्ट मोड में:

 SELECT jsonb '{"a":1}' @? 'strict $.b ? (@ > 1)'; ?column? ---------- (null) (1 row) 

यही है, जहां उदार मोड के तहत हमें FALSE प्राप्त हुआ, सख्त के साथ हमें NULL मिला।

लैक मोड में, एक जटिल पदानुक्रम [1,2, [3,4,5]] के साथ एक सरणी हमेशा [1,2,3,4,5] तक फैलती है:

 SELECT jsonb '[1,2,[3,4,5]]' @? 'lax $[*] ? (@ == 5)'; ?column? ---------- t (1 row) 

स्ट्रिक्ट मोड में, "5" नंबर नहीं मिलेगा, क्योंकि यह पदानुक्रम के नीचे नहीं है। इसे खोजने के लिए, आपको "@" को "@ [*]" से बदलकर क्वेरी को संशोधित करना होगा:

 SELECT jsonb '[1,2,[3,4,5]]' @? 'strict $[*] ? (@[*] == 5)'; ?column? ---------- t (1 row) 

PostgreSQL 12 में, JSONPath एक डेटा प्रकार है। मानक नए प्रकार की आवश्यकता के बारे में कुछ नहीं कहता है, यह कार्यान्वयन की संपत्ति है। नए प्रकार के साथ, हमें अपने काम को तेज करने वाले ऑपरेटरों और अनुक्रमितों की मदद से जसनाथ के साथ पूर्ण काम मिलता है, जो पहले से ही JSONB के लिए मौजूद हैं। अन्यथा, JSONPath को निष्पादक और अनुकूलक कोड के स्तर पर एकीकृत करना होगा।

आप SQL / JSON सिंटैक्स के बारे में पढ़ सकते हैं, उदाहरण के लिए, यहाँ ।

ओलेग बार्टुनोव का ब्लॉग पोस्ट SQL / JSON मानक -2016 अनुरूपता के लिए PostgreSQL, Oracle, SQL Server और MySQL के बारे में है।

यहाँ SQL / JSON पर एक प्रस्तुति है ।

और यहाँ SQL / JSON का परिचय है।