SQL क्वेरी को कैसे फ़ॉर्मेट करें
अव्यवस्थित SQL बग्स पेश करने के सबसे तेज़ तरीकों में से एक है। जब एक क्वेरी बिना इंडेंटेशन के एक लंबी लाइन है, तो यह देखना मुश्किल है कि कौन सी शर्तें किन जॉइन्स पर लागू होती हैं, सबक्वेरी कहाँ शुरू होती हैं और कहाँ समाप्त होती हैं, या लॉजिक सही है या नहीं। ब्राउज़र-आधारित फॉर्मेटर पूरा काम स्थानीय रूप से संभालता है, आपकी क्वेरीज़ को सर्वर पर अपलोड किए बिना।
फॉर्मेटिंग क्यों मायने रखती है
- डिबगिंग: एक अच्छी तरह से फॉर्मेट की गई क्वेरी लॉजिक त्रुटियों को दृश्यमान बनाती है। आप बिना अनुमान के SELECT से WHERE से JOIN तक प्रवाह को ट्रेस कर सकते हैं।
- कोड समीक्षा: समीक्षक सेकंडों में फॉर्मेट किए गए SQL को पढ़ सकते हैं। एक एकल-लाइन क्वेरी उन्हें पहले मानसिक रूप से इसे पार्स करने के लिए मजबूर करती है।
- रखरखाव: जब आप महीनों बाद क्वेरी पर लौटते हैं, फॉर्मेटिंग आपको एक नज़र में बताती है कि यह क्या करती है।
- सहयोग: एक टीम में सुसंगत फॉर्मेटिंग का मतलब है कि हर कोई SQL को उसी तरह पढ़ता है।
- ऑनबोर्डिंग: नए टीम सदस्य प्रत्येक क्वेरी के मौखिक इतिहास की आवश्यकता के बिना फॉर्मेट किया हुआ SQL पढ़ सकते हैं।
- दस्तावेज़ीकरण: जब SQL डिज़ाइन दस्तावेज़ों, रनबुक्स या विकीज़ में दिखाई देता है, तो फॉर्मेट की गई क्वेरीज़ गैर-डेवलपर्स के लिए अनुसरण करने में आसान होती हैं।
- संस्करण नियंत्रण अंतर: जब आप पूरी क्वेरी को रिफॉर्मेट किए बिना एक खंड बदलते हैं तो फॉर्मेट किया गया SQL साफ अंतर पैदा करता है।
SQL कैसे फॉर्मेट करें
- अपना SQL पेस्ट करें: फॉर्मेटर में एक मिनिफाइड या अव्यवस्थित क्वेरी दर्ज करें। यह SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, और सबक्वेरीज़ और जॉइन्स वाली जटिल क्वेरीज़ को संभालता है।
- विकल्प कॉन्फ़िगर करें: इंडेंटेशन आकार चुनें और क्या कीवर्ड्स को अपरकेस में करना है। ये सेटिंग्स आपके प्रोजेक्ट की स्टाइल गाइड से मेल खाती हैं।
- परिणाम कॉपी करें: फॉर्मेट किया गया SQL आपके संपादक, डेटाबेस क्लाइंट या दस्तावेज़ीकरण में वापस पेस्ट करने के लिए तैयार है।
अच्छी फॉर्मेटिंग कैसी दिखती है
select u.name, o.total from users u join orders o on u.id = o.user_id where o.total > 100 and u.active = 1 order by o.total desc जैसी क्वेरी बन जाती है:
SELECT
u.name,
o.total
FROM users u
JOIN orders o
ON u.id = o.user_id
WHERE o.total > 100
AND u.active = 1
ORDER BY o.total DESC
प्रत्येक खंड अपनी लाइन पर शुरू होता है। शर्तें उनके मूल खंड के तहत इंडेंट हैं। जॉइन्स और उनकी ON शर्तें स्पष्ट रूप से जोड़ी गई हैं।
SQL फॉर्मेटिंग सम्मेलनों का संक्षिप्त इतिहास
SQL को 1974 में IBM शोधकर्ताओं डोनाल्ड चेम्बरलिन और रेमंड बॉयस द्वारा बनाया गया था, जिसे मूल रूप से SEQUEL (Structured English Query Language) कहा जाता था। मूल नाम में «QL» ने भाषा के अंग्रेजी की तरह पढ़ने के इरादे को दर्शाया। शुरू से ही, इस मानव-पठनीय डिज़ाइन ने एक सम्मेलन का संकेत दिया: अपने खंडों को इंडेंट करें ताकि वे ऊपर से नीचे तक वाक्यों की तरह पढ़े जा सकें।
1980 और 1990 के दशक के अधिकांश समय के लिए, SQL को टेक्स्ट संपादकों में हाथ से लिखा जाता था और फॉर्मेटिंग व्यक्तिगत थी। कुछ दुकानों ने «नदी शैली» (जहाँ प्रत्येक कीवर्ड वर्चुअल कॉलम के दाईं ओर लंबवत रूप से संरेखित होता है) को अपनाया, अन्य ने «मिस्र शैली» (कर्ली-ब्रेस-समान-लाइन समकक्ष) का उपयोग किया, और अधिकांश ने बस वही उपयोग किया जो लेखक को पसंद था।
पहला व्यापक रूप से उपयोग किया जाने वाला SQL फॉर्मेटर Apex SQL Formatter (2000) था, उसके बाद Devart का SQL Complete (2002) और Red Gate का SQL Prompt (2003)। इन उपकरणों ने SQL Server और Oracle डेवलपर्स को IDE-स्तरीय फॉर्मेटिंग लाई। 2010 तक हर प्रमुख IDE (SSMS, DataGrip, DBeaver) में बिल्ट-इन SQL फॉर्मेटिंग थी, और ऑनलाइन फॉर्मेटर एड-हॉक सफाई के लिए मानक बन गए।
2017 में फॉर्मेटर पारिस्थितिकी तंत्र sql-formatter (npm) के साथ बदल गया, एक ओपन-सोर्स JavaScript लाइब्रेरी जो आज इस सहित अधिकांश ब्राउज़र-आधारित SQL फॉर्मेटर्स को पावर करती है। आधुनिक फॉर्मेटर्स बोली अंतर (MySQL बैकटिक्स, PostgreSQL विंडो फ़ंक्शंस, SQL Server स्क्वायर ब्रैकेट्स) को संभालते हैं और सुसंगत, कॉन्फ़िगर करने योग्य आउटपुट का उत्पादन करते हैं।
प्रमुख कंपनियों द्वारा उपयोग की जाने वाली SQL स्टाइल गाइड्स
अधिकांश पेशेवर कोडबेस कई प्रकाशित SQL स्टाइल गाइड्स में से एक का अनुसरण करते हैं:
| स्टाइल गाइड | उत्पत्ति | मुख्य सम्मेलन |
|---|---|---|
| Mozilla SQL Style | Mozilla | अपरकेस कीवर्ड्स, snake_case नाम, 2-स्पेस इंडेंट |
| GitLab SQL Style | GitLab Data Team | अपरकेस कीवर्ड्स, लोअरकेस नाम, 4-स्पेस इंडेंट, अग्रणी अल्पविराम |
| Holistics SQL Style | Holistics | अपरकेस कीवर्ड्स, snake_case, 2 स्पेस, अनुगामी अल्पविराम |
| Simon Holywell SQL | व्यक्तिगत/लोकप्रिय | «नदी» संरेखण, अपरकेस कीवर्ड्स |
| dbt SQL Style | dbt Labs | लोअरकेस कीवर्ड्स (आधुनिक बोली), snake_case, अग्रणी अल्पविराम |
| PostgreSQL Wiki Style | PostgreSQL समुदाय | लोअरकेस कीवर्ड्स, snake_case, K&R-शैली इंडेंटेशन |
यदि आप एक नया प्रोजेक्ट शुरू कर रहे हैं, तो स्थापित गाइड्स में से एक चुनें। यदि आप एक मौजूदा कोडबेस में शामिल हो रहे हैं, तो जो पहले से है उसका अनुसरण करें। एक प्रोजेक्ट के भीतर स्थिरता किसी भी विशिष्ट शैली से अधिक महत्वपूर्ण है।
सामान्य फॉर्मेटिंग विकल्प
- कीवर्ड केस: अपरकेस (सबसे आम, कीवर्ड्स को दृष्टि से अलग बनाता है), लोअरकेस (आधुनिक dbt/Snowflake शैली), या मूल केस (कुछ IDE आपके द्वारा टाइप किए गए को संरक्षित करते हैं)।
- पहचानकर्ता केस: snake_case PostgreSQL और अधिकांश यूनिक्स-अनुकूल डेटाबेस में डिफ़ॉल्ट है; PascalCase या camelCase Oracle/SQL Server परंपराओं में।
- इंडेंटेशन: 2 स्पेस (कॉम्पैक्ट, 80-वर्ण टर्मिनल में फिट होता है), 4 स्पेस (अधिकांश कोड स्टाइल गाइड्स से मेल खाता है), या टैब्स (SQL में दुर्लभ)।
- अल्पविराम प्लेसमेंट: अनुगामी अल्पविराम (प्रत्येक कॉलम के बाद अलग लाइन पर) या अग्रणी अल्पविराम (अगली लाइन की शुरुआत में अल्पविराम, कॉलम जोड़ने/हटाने में आसान)।
- लाइन लंबाई: 80 वर्ण (टर्मिनल-अनुकूल), 120 वर्ण (आधुनिक IDE डिफ़ॉल्ट), या असीमित (उत्पादन में कम सामान्य)।
- JOIN शैली: ANSI JOIN कीवर्ड (पसंदीदा) बनाम पुरानी शैली अल्पविराम-पृथक FROM के साथ WHERE जॉइन शर्तें (अप्रचलित)।
- सबक्वेरी फॉर्मेटिंग: कोष्ठक के अंदर सबक्वेरीज़ को इंडेंट करें, स्पष्टता के लिए कॉमन टेबल एक्सप्रेशन (CTE) का उपयोग करें, या स्पष्ट उपनामों के साथ नेस्ट करें।
बोली अंतर
SQL फॉर्मेटर्स को बोली-विशिष्ट सिंटैक्स को संभालने की आवश्यकता है:
| बोली | विशिष्ट विशेषताएं |
|---|---|
| PostgreSQL | विंडो फ़ंक्शन, LATERAL JOINS, डॉलर-उद्धृत स्ट्रिंग्स ($$), CTE-गहन शैली |
| MySQL/MariaDB | बैकटिक पहचानकर्ता, LIMIT क्लॉज़ सिंटैक्स, REPLACE INTO |
| SQL Server (T-SQL) | स्क्वायर ब्रैकेट पहचानकर्ता, TOP क्लॉज़, OUTPUT क्लॉज़, MERGE |
| Oracle (PL/SQL) | DUAL तालिका, ROWNUM, पदानुक्रमित CONNECT BY, डॉट-प्रत्यय पैकेज कॉल |
| SQLite | सीमित प्रकार प्रणाली, REPLACE/UPSERT, एकल-फ़ाइल डेटाबेस |
| Snowflake | संस्करण डेटा प्रकार, QUALIFY क्लॉज़, COPY INTO |
| BigQuery | बैकटिक पहचानकर्ता, ARRAY/STRUCT प्रकार, EXCEPT/REPLACE कॉलम सूची |
| Redshift | PostgreSQL-व्युत्पन्न लेकिन विशिष्ट DDL, S3 से COPY |
एक अच्छा फॉर्मेटर बोली संकेत का पता लगाता है या स्वीकार करता है, फिर उन सिंटैक्स को संभालता है जिन्हें अन्य बोलियाँ अस्वीकार करेंगी।
सामान्य चूक
- उत्पादन स्क्रिप्ट के अंदर पुन: फॉर्मेटिंग: एक माइग्रेशन स्क्रिप्ट में व्हाइटस्पेस बदलना जो पहले से ही आंशिक रूप से लागू किया जा चुका है, समस्याएं पैदा कर सकता है यदि आपका माइग्रेशन टूल हैश द्वारा फिंगरप्रिंट करता है। पहले रन से पहले फॉर्मेट करें।
- स्ट्रिंग साहित्य पुन: फॉर्मेटेड: क्वेरी के अंदर एक मल्टीलाइन स्ट्रिंग को SQL फॉर्मेटर द्वारा रिफॉर्मेट नहीं किया जाना चाहिए; कुछ भोले फॉर्मेटर्स इनलाइन स्ट्रिंग्स को तोड़ देते हैं।
- टिप्पणियाँ खो गईं या गलत जगह पर हैं: SQL टिप्पणियाँ (एकल-लाइन डैश और मल्टीलाइन स्लैश-स्टार) को फॉर्मेटिंग में जीवित रहना चाहिए। कुछ फॉर्मेटर्स उन्हें छोड़ देते हैं या भ्रामक तरीकों से स्थानांतरित करते हैं।
- पहचानकर्ता उद्धरण बदला गया: PostgreSQL में दोहरे-उद्धृत पहचानकर्ता या MySQL में बैकटिक पहचानकर्ता के विशिष्ट अर्थ हैं। एक फॉर्मेटर जो उद्धरण हटाकर «सामान्यीकरण» करता है, क्वेरी के व्यवहार को बदल सकता है यदि पहचानकर्ता को उद्धरण की आवश्यकता थी (आरक्षित शब्द, PostgreSQL में मिश्रित केस)।
- विंडो फ़ंक्शन गलत फॉर्मेटेड: OVER (PARTITION BY x ORDER BY y) को पठनीय रहना चाहिए। विंडो फ़ंक्शन कोष्ठक के अंदर आक्रामक लाइन-रैपिंग अव्यवस्थित आउटपुट उत्पन्न करती है।
- CTE श्रृंखलाएं अधिक इंडेंट: WITH cte1 AS (...), cte2 AS (...) कुछ फॉर्मेटर्स द्वारा बहुत गहराई से नेस्ट हो सकता है। अधिकांश आधुनिक फॉर्मेटर्स CTE को शीर्ष स्तर पर रखते हैं।
- डॉलर-उद्धृत स्ट्रिंग्स (PostgreSQL फ़ंक्शन): $$ में लिपटे फ़ंक्शन निकायों को अपनी सामग्री को रिफॉर्मेट नहीं करना चाहिए। कुछ फॉर्मेटर्स उन्हें विकृत करते हैं।
- विक्रेता-विशिष्ट कीवर्ड्स गलत वर्गीकृत: एक फॉर्मेटर जो QUALIFY (Snowflake) या LATERAL (PostgreSQL) के बारे में अवगत नहीं है, उन्हें सही ढंग से कैपिटलाइज़ या संरेखित नहीं कर सकता।
- नियंत्रण प्रवाह के साथ संग्रहीत प्रक्रियाएं: T-SQL या PL/SQL में BEGIN/END, IF/THEN/ELSE ब्लॉकों को शुद्ध क्वेरी से अलग इंडेंटेशन नियमों की आवश्यकता होती है।
सुझाव
- कमिट करने से पहले फॉर्मेट करें: संस्करण नियंत्रण में जोड़ने से पहले अपने SQL को फॉर्मेटर के माध्यम से चलाएं। यह डिफ़्स को साफ रखता है और समीक्षाओं को तर्क पर केंद्रित रखता है, शैली पर नहीं।
- सुसंगत कीवर्ड केसिंग का उपयोग करें: अपरकेस या लोअरकेस कीवर्ड्स चुनें और अपने पूरे प्रोजेक्ट में उसके साथ बने रहें। मिश्रण शैलियाँ क्वेरीज़ को पढ़ने में कठिन बनाती हैं।
- जटिल क्वेरीज़ को तोड़ें: यदि एक क्वेरी फॉर्मेटिंग के बाद भी पढ़ने में कठिन है, तो इसे CTE (कॉमन टेबल एक्सप्रेशन) या व्यू में तोड़ने पर विचार करें। फॉर्मेटिंग मौलिक रूप से जटिल तर्क को ठीक नहीं कर सकती।
- सिंटैक्स हाइलाइटिंग की जांच करें: एक अच्छा फॉर्मेटर रंग-कोडित हाइलाइटिंग प्रदान करता है जो कीवर्ड्स, स्ट्रिंग्स और संख्याओं को दृष्टि से अलग बनाता है, जो टाइपो पकड़ने में मदद करता है।
- केवल वही फॉर्मेट करें जो आप बदलते हैं: एक बड़े मौजूदा कोडबेस में, एक बार में सब कुछ रिफॉर्मेट करना एक बड़ा डिफ पैदा करता है जो वास्तविक परिवर्तनों को अस्पष्ट करता है। जब आप क्वेरीज़ को छूते हैं तो वृद्धिशील रूप से फॉर्मेट करें।
- अपना एडिटर सेट करें: VS Code (SQLTools, vscode-sql-formatter), DataGrip, DBeaver, और pgAdmin सभी में अंतर्निहित या एक्सटेंशन-आधारित फॉर्मेटर हैं। एक बार कॉन्फ़िगर करें और भूल जाएं।
- केस-सेंसिटिव डेटाबेस से सावधान रहें: PostgreSQL उद्धृत पहचानकर्ताओं के लिए केस-सेंसिटिव है। एक फॉर्मेटर जो उद्धृत पहचानकर्ताओं के केस को बदलता है, क्वेरीज़ को तोड़ देगा।
- फॉर्मेट की गई क्वेरी का परीक्षण करें: रिफॉर्मेट करने के बाद, यह सत्यापित करने के लिए क्वेरी चलाएं कि आउटपुट अपरिवर्तित है। अधिकांश फॉर्मेटर्स विश्वसनीय हैं, लेकिन फॉर्मेटर में एक बग एक क्वेरी को दूषित कर सकता है।
- नेस्टेड सबक्वेरीज़ के बजाय CTE का उपयोग करें: एक CTE श्रृंखला लगभग हमेशा फॉर्मेटिंग के बाद भी समकक्ष नेस्टेड सबक्वेरी की तुलना में पढ़ने और डिबग करने में आसान होती है।
गोपनीयता और गोपनीय क्वेरीज़
SQL फॉर्मेटर पूरी तरह से आपके ब्राउज़र में चलता है। आप जो क्वेरीज़ पेस्ट करते हैं, मध्यवर्ती प्रसंस्करण, और फॉर्मेट किया गया आउटपुट सभी आपके डिवाइस पर रहते हैं। कुछ भी सर्वर पर अपलोड नहीं किया जाता, लॉग नहीं किया जाता, या किसी के साथ साझा नहीं किया जाता।
यह महत्वपूर्ण है क्योंकि SQL क्वेरीज़ में अक्सर अत्यंत संवेदनशील जानकारी होती है: तालिका नाम जो उत्पाद आर्किटेक्चर को प्रकट करते हैं, कॉलम नाम जो व्यावसायिक तर्क और मेट्रिक्स को उजागर करते हैं, WHERE क्लॉज़ में वास्तविक ग्राहक ID, संग्रहीत प्रक्रियाओं में आंतरिक API एंडपॉइंट्स, परीक्षण डेटा में SSN और क्रेडिट कार्ड नंबर, HR क्वेरीज़ में कर्मचारी मुआवजा, एनालिटिक्स क्वेरीज़ में वित्तीय आंकड़े, मार्केटिंग क्वेरीज़ में ग्राहक ईमेल पते। क्लाउड SQL फॉर्मेटर्स अपने अनुरोध लॉग में प्रत्येक क्वेरी को लॉग करते हैं, कभी-कभी «सेवा सुधार» के लिए उन्हें बनाए रखते हैं, और वास्तविक उल्लंघनों में शामिल रहे हैं जहाँ चिपकाई गई उत्पादन क्वेरीज़ ने संवेदनशील स्कीमा और डेटा लीक किया। ब्राउज़र-आधारित फॉर्मेटर में शून्य एक्सपोज़र है: क्वेरी कभी आपकी मशीन नहीं छोड़ती।
ब्राउज़र-आधारित फॉर्मेटिंग पृष्ठ लोड होने के बाद ऑफ़लाइन भी काम करती है, हवाई जहाज़ों पर, इंटरनेट एक्सेस के बिना सुरक्षित वातावरण में, या कहीं भी जहाँ आप किसी तृतीय पक्ष सेवा में डेटाबेस क्वेरी पेस्ट नहीं कर सकते या नहीं करना चाहिए, क्वेरीज़ को फॉर्मेट करने के लिए उपयोगी।
अक्सर पूछे जाने वाले प्रश्न
क्या SQL कीवर्ड बड़े अक्षरों में लिखे जाने चाहिए?
SQL कीवर्ड (SELECT, FROM, WHERE) को बड़े अक्षरों में और तालिका या कॉलम नामों को छोटे अक्षरों में लिखना व्यापक रूप से अनुसरण किया जाने वाला सम्मेलन है। यह क्वेरी को दृश्य रूप से पढ़ना आसान बनाता है। अधिकांश शैली गाइड इसकी अनुशंसा करती हैं, लेकिन कोई भी डेटाबेस इंजन इसे थोपता नहीं है।
क्या फ़ॉर्मेटिंग क्वेरी के निष्पादन को बदलती है?
नहीं। रिक्त स्थान और इंडेंटेशन का SQL निष्पादन पर कोई प्रभाव नहीं होता। फ़ॉर्मेटिंग पूरी तरह मानव पठनीयता के लिए है। एक मिनीफ़ाई और एक इंडेंट की गई क्वेरी समान परिणाम उत्पन्न करती हैं।
कौन सा इंडेंटेशन आकार उपयोग करें?
दो या चार स्पेस दोनों सामान्य हैं। चुनें कि आपकी टीम क्या उपयोग करती है और सुसंगत रहें। अधिकांश SQL फ़ॉर्मेटर इसे कॉन्फ़िगर करने की अनुमति देते हैं।
क्या मेरा SQL किसी सर्वर पर भेजा जाता है?
नहीं। फ़ॉर्मेटिंग पूरी तरह आपके ब्राउज़र में होती है। आपकी क्वेरी कभी आपके डिवाइस से बाहर नहीं जातीं।