क्या SQL में SELECT से पहले FROM नहीं आना चाहिए? (2011)

मूल लेख ↗ Hacker News चर्चा ↗

SQL में `FROM` को `SELECT` से पहले रखना चाहिए या नहीं, यह इस बात पर गहरी बहस को छूता है कि क्वेरी भाषाएँ मानवीय पठनीयता, निष्पादन अर्थ, और टूलिंग समर्थन के बीच संतुलन कैसे बनाती हैं। टिप्पणीकारों का कहना है कि मौजूदा अंग्रेज़ी-जैसी `SELECT ... FROM ...` सिंटैक्स ऑटोकम्प्लीट जैसी सुविधाओं को बाधित करता है और तार्किक निष्पादन क्रम को अस्पष्ट बनाता है, जबकि `LINQ`, `Kusto`, `PRQL`, और `DuckDB` जैसे विकल्प दिखाते हैं कि `FROM`-first या पाइपलाइन-शैली के रूप अधिक एर्गोनॉमिक हो सकते हैं। अन्य लोग तर्क देते हैं कि SQL की उम्र, उसका इकोसिस्टम लॉक-इन, और गैर-इंजीनियरों के लिए समझने योग्य होने का उसका मूल उद्देश्य बड़े सिंटैक्स परिवर्तन को असंभव बनाते हैं, इसलिए बेहतर टूलिंग या companion DSLs अधिक यथार्थवादी रास्ते हैं।

FROM बनाम SELECT क्रम

  • कई लोग तर्क देते हैं कि FROM … SELECT … लोगों की सोच के तरीके से बेहतर मेल खाता है: पहले डेटा स्रोत(स्रोतों) को परिभाषित करो, फिर फ़िल्टर/समूह बनाओ, फिर कॉलम चुनो।
  • समर्थकों का कहना है कि यह उस क्रम को भी दर्शाता है जिसमें क्वेरीज़ निष्पादित होती हैं, और बड़े, जटिल SQL फ़ाइलों को संभालना तथा मानसिक रूप से मॉडल करना आसान बना देगा।
  • कुछ लोग SELECT … FROM … का बचाव करते हैं क्योंकि यह “कमांड” (select/insert/update/delete) से शुरू होता है, जो इस बात से मेल खाता है कि स्टेटमेंट्स को कैसे वर्गीकृत और फ़ाइलों में स्कैन किया जाता है।
  • अंग्रेज़ी जैसी बनावट का हवाला दोनों तरफ़ से दिया जाता है: सरल क्वेरीज़ “select X from Y” की तरह स्वाभाविक पढ़ी जाती हैं, लेकिन अधिक जटिल, बहु-क्रियात्मक स्टेटमेंट्स संभवतः “from” पहले होने पर बेहतर पढ़ती हैं।

टूलिंग, ऑटोकम्प्लीट, और IDE UX

  • एक बार-बार उठने वाली शिकायत: SELECT पहले होने पर, IDEs FROM लिखे जाने तक कॉलम कम्प्लीशन नहीं दे सकते।
  • FROM-first सिंटैक्स (LINQ, Kusto/KQL, PRQL, DuckDB का वैकल्पिक FROM-first मोड, NRQL, ABAP OpenSQL) को बेहतर intellisense और चरणबद्ध, संयोज्य क्वेरींग सक्षम करने के लिए सराहा जाता है।
  • कुछ लोग मानते हैं कि स्मार्ट IDEs मौजूदा SQL के आसपास काम कर सकते हैं, जबकि दूसरों का कहना है कि भाषा-स्तरीय समर्थन फिर भी एक बड़ा एर्गोनॉमिक लाभ है।

निष्पादन क्रम बनाम सिंटैक्स क्रम

  • कई पोस्ट SQL के शाब्दिक क्रम (SELECT → FROM → WHERE → …) की तुलना उसके “तार्किक” प्रोसेसिंग क्रम (FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY) से करती हैं।
  • इस असंगति को पढ़ाने और मानसिक मॉडल के लिए दर्दनाक माना जाता है, खासकर नए लोगों के लिए जो अपेक्षा करते हैं कि पहले वाले क्लॉज़ बाद वाले को “देख” सकें।

सुरक्षा और UPDATE सिंटैक्स

  • UPDATE … SET … WHERE … बहुतों को परेशान करता है क्योंकि SET WHERE से पहले आता है; लोग गलती से WHERE छोड़ देने से डरते हैं।
  • आम उपाय: WHERE पहले लिखना, UPDATE में बदलने से पहले SELECT के रूप में प्रोटोटाइप बनाना, और स्पष्ट transactions (BEGIN/ROLLBACK, ऐसे टूल्स जो WHERE-less updates पर चेतावनी दें) का उपयोग करना।

डिज़ाइन लक्ष्य, अंग्रेज़ी-जैसी बनावट, और विकल्प

  • SQL को पुराना, अंग्रेज़ी-प्रभावित, और गैर-तकनीकी उपयोगकर्ताओं के लिए डिज़ाइन किया गया बताया गया है; इसके quirks नेटवर्क इफ़ेक्ट्स के कारण बने रहते हैं।
  • कई पोस्ट सुझाव देती हैं कि SQL “काफ़ी अच्छा” है लेकिन composition के लिए गड़बड़ है, और specialized query languages या compile-to-SQL DSLs (PRQL, SaneQL, HoneySQL, Datalog-जैसी प्रणालियाँ, QUEL-शैली का सिंटैक्स) का समर्थन करती हैं।
  • कुछ का तर्क है कि DBs को मनुष्यों के लिए SQL और मशीनों के लिए एक अलग, अधिक संरचित API देना चाहिए।