SQL की समस्याएँ और उनके समाधान: SQL की pipe syntax

 (research.google)
13 पॉइंट द्वारा GN⁺ 2024-08-26 | 11 टिप्पणियां | WhatsApp पर शेयर करें
  • SQL पिछले 50 वर्षों से structured data processing की बुनियादी भाषा रही है, लेकिन इसे सीखना कठिन है, इस्तेमाल करना झंझटपूर्ण है, और इसे विस्तार देना मुश्किल है
  • मौजूदा SQL की समस्याएँ: syntax order की अनिवार्यता, दोहराया हुआ syntax, subquery की आवश्यकता, 'अंदर से बाहर' data flow, extensibility की कमी आदि
  • GoogleSQL ने SQL की समस्याओं को हल करने के लिए SQL को extend करने का दृष्टिकोण अपनाया है
    • SQL में pipe-structured data flow syntax लाकर मौजूदा SQL की समस्याओं को हल करने की कोशिश की गई है
    • इससे मौजूदा ecosystem को बनाए रखते हुए SQL को सीखना और इस्तेमाल करना अधिक लचीला हो जाता है, और मौजूदा SQL के साथ पूर्ण compatibility भी बनी रहती है
      • मौजूदा SQL operators का पुन: उपयोग किया जा सकता है और उन्हें pipes के साथ मनचाहे क्रम में संयोजित किया जा सकता है
      • हर pipe operator केवल input table को देखता है, इसलिए उसका scope स्पष्ट रहता है
      • declarative semantics बनी रहती है
      • relational algebra के साथ one-to-one mapping संभव हो जाती है
      • table-valued functions के जरिए extensibility बेहतर होती है
    • उदाहरण के लिए, multi-stage aggregation को subquery के बिना लगातार व्यक्त किया जा सकता है
    • pipe syntax का उपयोग करने वाला SQL सीखने और इस्तेमाल करने में आसान है, और विभिन्न operators को मनचाहे क्रम में लागू किया जा सकता है, जिससे flexibility काफ़ी बढ़ जाती है
    • pipe operators क्रमिक रूप से काम करते हैं, जिससे उपयोगकर्ता data को अधिक आसानी से filter, aggregate और sort कर सकते हैं
  • GoogleSQL में उपयोग का अनुभव
    • उपयोगकर्ताओं से लगातार adoption और सकारात्मक feedback मिला है
    • जटिल query को भी linear रूप में व्यक्त किया जा सकता है
    • editing और debugging कार्यों में सुविधा होती है
    • IDE tool support बेहतर होता है
    • SQL code generators और converters के लिए लाभदायक है
    • AI अनुप्रयोगों के लिए संभावित फायदे हैं
  • implementation और आगे की योजना
    • GoogleSQL में pipe syntax को shared component के रूप में implement किया गया है
    • मौजूदा query engines इस pipe syntax को आसानी से enable कर सकते हैं
    • BigQuery और Spanner में इसे बाहरी रूप से support करने पर विचार किया जा रहा है
    • भविष्य में इसे SQL standard में शामिल करने की संभावना तलाशना सार्थक हो सकता है

GN⁺ की राय

  • pipe syntax के फायदे: यह SQL की जटिलता को हल करने वाला एक शक्तिशाली tool बन सकता है, खासकर क्योंकि यह data flow को सहज रूप से व्यक्त कर सकता है और SQL की usability को बहुत बेहतर बना सकता है।
  • मौजूदा SQL के साथ compatibility: यह मौजूदा SQL को बदलने के बजाय उसे बेहतर बनाने का दृष्टिकोण अपनाता है, जिससे learning curve कम हो सकती है और मौजूदा code के साथ compatibility बनी रह सकती है।
  • अपनाने के समय ध्यान देने योग्य बातें: pipe syntax अपनाते समय performance पर उसके प्रभाव और tool support के स्तर पर विचार करना चाहिए, खासकर बड़े पैमाने की queries में इसके फायदे का अधिकतम उपयोग किया जा सकता है।
  • समान परियोजनाओं से तुलना: Pandas जैसी DataFrame APIs में भी pipe structure का उपयोग होता है, लेकिन SQL से इसका फर्क SQL की declarative semantics के साथ इसके संयोजन में है। SQL systems की extensibility और performance बनाए रखते हुए इस तरह की सुविधा का उपयोग किया जा सकता है।

संबंधित पढ़ाई

11 टिप्पणियां

 
dkang 2024-08-26

पाइप पर caret? यह तो कुछ ऐसा कॉम्बिनेशन लगता है जिससे दायाँ हाथ दुखने लगेगा 🤣
अभी के SQL में वाकई कुछ सुधार की ज़रूरत तो है।
लेकिन समस्या यह है कि करीब 30-40 साल से कोई सुधार का तरीका नहीं मिल पाया है..
 
savvykang 2024-08-26

मुझे लगता है कि SQL के अतिरिक्त syntax के मामले में ecosystem को Google को lead करना चाहिए, लेकिन क्या उनकी business unit इसे वाकई लंबे समय तक जारी रखेगी?
 
chusine 2024-08-26

यह तो dplyr है हाहाहा
 
koreaisbest 2024-08-26

पता नहीं क्यों, जब Google कुछ करता है तो बस लगता है कि वह फेल ही होगा..
Gemini तो ऐसे जवाब देता है जैसे कोई बच्चा बोल रहा हो, इसलिए उसे इस्तेमाल करने का भी मन नहीं करता
 
ilotoki0804 2024-08-26

यह ORM द्वारा अपनाए जाने वाले approach जैसा ही लगता है।
 
winterjung 2024-08-26

पेपर के नीचे दिए गए उदाहरण को देखकर भी साफ़ लगता है कि google sql पढ़ने में ज़्यादा आसान है।

standard sql

SELECT c_count, COUNT(*) AS custdist  
FROM  
    ( SELECT c_custkey, COUNT(o_orderkey) c_count  
      FROM customer  
      LEFT OUTER JOIN orders ON c_custkey = o_custkey  
           AND o_comment NOT LIKE '%unusual%packages%'  
      GROUP BY c_custkey  
    ) AS c_orders  
GROUP BY c_count  
ORDER BY custdist DESC, c_count DESC;

google sql

FROM customer  
|> LEFT OUTER JOIN orders ON c_custkey = o_custkey  
      AND o_comment NOT LIKE '%unusual%packages%'  
|> AGGREGATE COUNT(o_orderkey) c_count  
   GROUP BY c_custkey  
|> AGGREGATE COUNT(*) AS custdist  
   GROUP BY c_count  
|> ORDER BY custdist DESC, c_count DESC;
 
mwma91 2024-08-30

C# का LINQ याद आ रहा है। जब भी SQL इस्तेमाल करता था, हमेशा यही लगता था कि SELECT का क्रम बदलकर FROM, WHERE के बाद आ जाए तो अच्छा होगा....
शुरुआत में अनजान होने की वजह से अटपटा लगे, फिर भी धीरे-धीरे पढ़ें तो इसका flow कहीं ज़्यादा स्वाभाविक महसूस होता है.
 
regentag 2024-08-27

मुझे लगता है कि SQL वाला पक्ष पढ़ने में ज़्यादा बेहतर है।
 
leftliber 2024-08-27

मुझे तो SQL वाला पक्ष कहीं ज़्यादा पढ़ने में आसान लगता है। हाहा, शायद जिन लोगों ने SQL से शुरुआत की है, वे ज़्यादातर ऐसा ही महसूस करते होंगे...
 
superwoou 2024-08-28

मुझे भी जो चीज़ ज़्यादा familiar है, उसे पढ़ना थोड़ा आसान लगता है.. haha
 
GN⁺ 2024-08-26
Hacker News राय
  • SQL pipe syntax अब अधिक पढ़ने योग्य हो गई है
  • Google में SQL queries लिखते समय pipe syntax उपयोगी रही
  • उम्मीद है कि SQL pipe syntax आम हो जाएगी
  • Google AI Studio में PDF को HTML में बदलकर देखा, और परिणाम अच्छे थे
  • 20 साल से अधिक समय से SQL का उपयोग कर रहा हूँ, लेकिन अब भी कुछ queries को व्यक्त करना मुश्किल लगता है
  • Google के open source ZetaSQL प्रोजेक्ट ने pipe syntax documentation जोड़ी है
  • SQL के syntax को लेकर असंतोष की प्राथमिकता कम है
    • algebraic data types, true boolean logic, और functional composition जैसी सुविधाओं की ज़रूरत है
  • SQL लिखने की कठिनाई कम करने के लिए कई प्रयास हुए, लेकिन सफल नहीं रहे
    • लेखकों का approach क्रमिक है और मौजूदा SQL उपयोगकर्ताओं के लिए उपयुक्त है
  • pipeline syntax मौजूदा स्थिति से बेहतर है
    • query execution को कार्यों के directional graph के रूप में मॉडल करने वाली syntax और बेहतर होगी
      • join को दो या अधिक data streams को consume करके एक data stream बनाने वाले "cross-reference" कार्य के रूप में मॉडल किया जा सकता है
      • CTE को कई data streams बनाने वाले रूप में मॉडल किया जा सकता है
      • recursive CTE को execution graph के cycle के रूप में मॉडल किया जा सकता है
  • Elixir जैसा लगता है
    • अगर मौजूदा SQL syntax supported रहे तो ठीक है, लेकिन कई JOINs, subqueries, और aggregations वाली queries की readability कम हो सकती है
  • PRQL और Splunk के SPL की याद दिलाता है