सामग्री पर जाएं

एसक्यूएल फॉर्मेटर और वैलिडेटर - ऑनलाइन मुफ्त में एसक्यूएल क्वेरी फॉर्मेट करें

मुफ्त एसक्यूएल फॉर्मेटर और वैलिडेटर। स्वचालित रूप से उचित इंडेंटेशन और कैपिटलाइजेशन के साथ एसक्यूएल फॉर्मेट करें। तुरंत सिंटैक्स त्रुटियों की जाँच करें। माईएसक्यूएल, पोस्टग्रेएसक्यूएल, एसक्यूएल सर्वर, ओरेकल के साथ काम करता है।

SQL फॉर्मेटर और वैलिडेटर

स्वचालित इंडेंटेशन, कीवर्ड कैपिटलाइजेशन और सिंटैक्स त्रुटि पहचान के साथ SQL क्वेरी को फॉर्मेट और वैलिडेट करें।

फॉर्मेटेड परिणाम देखने के लिए SQL क्वेरी दर्ज करें।
लोडिंग कैलकुलेटर...
📚

दस्तावेज़ीकरण

SQL स्वरूपण क्यों महत्वपूर्ण है

क्या आपको कभी ऐसा डेटाबेस प्रोजेक्ट मिला है जहाँ SQL ऐसा दिखता है जैसे किसी ने आँखें बंद करके टाइप किया हो? आप अकेले नहीं हैं। खराब स्वरूपित SQL डेटाबेस विकास में बग्स और बर्बाद समय के सबसे सामान्य स्रोतों में से एक है।

यह SQL स्वरूपक और वैलिडेटर आपको स्वचालित रूप से अस्यवस्थित क्वेरी को साफ करने में मदद करता है। अपना SQL पेस्ट करें, और यह तुरंत उचित इंडेंटेशन लागू करता है, कीवर्ड को बड़े अक्षरों में लिखता है, और सिंटैक्स त्रुटियों की जाँच करता है—सब कुछ आपके ब्राउज़र में बिना किसी सर्वर पर डेटा भेजे। जो आमतौर पर मैनुअल स्वरूपण में 10-15 मिनट लगते हैं, वह अब सेकंडों में हो जाता है।

मेरे डेटाबेस टीमों के साथ काम करने के अनुभव में, सबसे बड़ी समय बचत स्वरूपण ही नहीं है—बल्कि उत्पादन में आने से पहले त्रुटियों को पकड़ना है। एक गलत स्थान पर रखा गया कोष्ठक या बंद न किया गया उद्धरण डीबग करने में घंटों बर्बाद कर सकता है। यह टूल उन मुद्दों को तुरंत पकड़ लेता है, इससे पहले कि आप अपने डेटाबेस पर कुछ भी निष्पादित करें।

SQL फॉर्मेटर का उपयोग कैसे करें

इंटरफ़ेस जानबूझकर न्यूनतम है—बस पेस्ट करें और आगे बढ़ें:

  1. अपना SQL इनपुट बॉक्स में पेस्ट करें (या यदि शुरू से लिख रहे हैं तो सीधे टाइप करें)
  2. जैसे-जैसे टाइप करते हैं स्वचालित रूप से फॉर्मेट होते देखें—कोई बटन क्लिक करने की आवश्यकता नहीं, कोई सेटिंग्स कॉन्फ़िगर करने की आवश्यकता नहीं
  3. सत्यापन त्रुटियों की समीक्षा करें यदि कोई फॉर्मेट किए गए आउटपुट के नीचे दिखाई दें
  4. फॉर्मेट किया गया SQL एक क्लिक में कॉपी करें अपने IDE, दस्तावेज़ीकरण या डेटाबेस टूल में उपयोग करने के लिए

किसी भी ब्राउज़र वाले डिवाइस पर काम करता है। फॉर्मेटिंग पूरी तरह से क्लाइंट-साइड होती है, इसलिए आपके क्वेरी कभी आपकी मशीन से नहीं जाते—जब उत्पादन डेटाबेस संरचनाओं या संवेदनशील योजनाओं के साथ काम कर रहे हों तो यह महत्वपूर्ण है।

SQL फॉर्मेटर क्या करता है

कीवर्ड कैपिटलाइज़ेशन

सभी SQL कीवर्ड स्वचालित रूप से कैपिटल हो जाते हैं—SELECT, FROM, WHERE, JOIN, और इसी तरह। यह अधिकांश डेटाबेस टीमों द्वारा उपयोग की जाने वाली परंपरा का पालन करता है और कीवर्ड को आपके टेबल और कॉलम नाम से दृश्य रूप से अलग करता है। जब आप एक जटिल क्वेरी में स्कैन कर रहे होते हैं, तो यह दृश्य अलगाव आपको एक नज़र में क्वेरी संरचना की पहचान करने में मदद करता है।

स्मार्ट इंडेंटेशन

फॉर्मेटर आपके SQL को तार्किक पदानुक्रम के आधार पर संरचित करता है, न कि बस यादृच्छिक लाइन ब्रेक जोड़कर। मुख्य क्लॉज़ जैसे SELECT और FROM बाएं मार्जिन पर शुरू होते हैं। JOIN क्लॉज़ FROM के नीचे इंडेंट होते हैं ताकि दिखाया जा सके कि वे टेबल चयन का हिस्सा हैं। सबक्वेरी को अतिरिक्त इंडेंटेशन स्तर मिलते हैं, जिससे नेस्टेड लॉजिक स्पष्ट हो जाता है।

व्यवहार में यह क्या होता है: जब आपके पास कई जॉइन और सबक्वेरी वाली एक क्वेरी होती है, तो उचित इंडेंटेशन आपको हर शब्द पढ़े बिना क्वेरी संरचना देखने में मदद करता है। आप तुरंत देख सकते हैं कि एक जॉइन कहां समाप्त होता है और दूसरा कहां शुरू होता है, या SELECT सूची में कहां सबक्वेरी का उपयोग किया जा रहा है।

तार्किक लाइन ब्रेक

लाइन ब्रेक वहां दिखाई देते हैं जहां वे पठनीयता में सहायक होते हैं, न कि हर जगह। प्रत्येक मुख्य क्लॉज़ को अपनी लाइन मिलती है। कॉमा से अलग की गई सूची में आइटम (जैसे SELECT में कॉलम नाम) को उचित इंडेंटेशन के साथ अपनी लाइन मिलती है। सबक्वेरी को दृश्य रूप से अलग किया जाता है। स्पष्टता के लिए CASE स्टेटमेंट WHEN, THEN, और ELSE पर ब्रेक होते हैं।

स्पेसिंग उद्योग में उपयोग किए जाने वाले SQL स्टाइल गाइड सम्मेलनों का पालन करती है, जिसका अर्थ है कि आपका फॉर्मेटेड SQL अन्य डेवलपर्स के लिए परिचित दिखेगा।

SQL सत्यापन: क्या जाँचा जाता है

वैलिडेटर उन त्रुटियों को पकड़ता है जो आमतौर पर तेजी से SQL लिखते समय चूक जाती हैं। यह आपके डेटाबेस के क्वेरी विश्लेषक की जगह नहीं लेता, लेकिन क्वेरी चलाने से पहले सामान्य गलतियों को पकड़ता है।

संरचनात्मक त्रुटियाँ

असंतुलित कोष्ठक जटिल क्वेरी में जहाँ नेस्टेड सब-क्वेरी होती हैं, वहाँ आश्चर्यजनक रूप से सामान्य हैं। वैलिडेटर खुले और बंद कोष्ठकों को गिनता है ताकि बेमेल को तुरंत चिह्नित किया जा सके। मैंने 200-लाइन की क्वेरी में एक ही गायब कोष्ठक के कारण उत्पादन की घटनाएँ देखी हैं—यह उन्हें जल्दी पकड़ता है।

बंद न किए गए स्ट्रिंग लिटरल तब होते हैं जब आप स्ट्रिंग मान पर समापन उद्धरण भूल जाते हैं। आपका डेटाबेस इन्हें तुरंत अस्वीकार कर देगा, लेकिन यहाँ पकड़ने से एक राउंड ट्रिप बचता है।

क्लॉज क्रम संबंधी समस्याएँ तब चिह्नित होती हैं जब क्लॉज अनुक्रम में नहीं होते। उदाहरण के लिए, अगर आप HAVING को GROUP BY से पहले रखते हैं, या WHERE को GROUP BY के बाद, वैलिडेटर आपको सचेत करता है। यह ISO/IEC 9075 SQL मानक में परिभाषित SQL मानक सिंटैक्स नियमों का पालन करता है।

तार्किक त्रुटियाँ

ON शर्तों के बिना JOIN क्लॉज अनजाने में क्रॉस जॉइन बनाते हैं, जिससे अपेक्षा से कहीं अधिक पंक्तियाँ लौटती हैं। एक सामान्य परिदृश्य: आप क्वेरी में तीसरी या चौथी तालिका जोड़ रहे हैं और ON क्लॉज भूल जाते हैं। इस जाँच के बिना, आप तब तक नहीं देख पाएंगे जब तक अपने परिणामों में हजारों डुप्लीकेट पंक्तियाँ न दिखें।

GROUP BY के बिना HAVING अधिकांश डेटाबेस में तकनीकी रूप से अमान्य SQL है। HAVING क्लॉज समूहीकृत परिणामों को फ़िल्टर करता है, इसलिए इसके काम करने के लिए GROUP BY की आवश्यकता होती है। वैलिडेटर इस तार्किक बेमेल को पकड़ता है।

अपूर्ण WHERE शर्तें तब होती हैं जब आप एक शर्त टाइप करना शुरू करते हैं लेकिन उसे पूरा नहीं करते—जैसे कोई मान के बिना WHERE status =। क्वेरी संपादित करते समय इन्हें चूकना आसान है।

जो यह नहीं पकड़ेगा

यह वैलिडेटर सिंटैक्स और संरचना पर केंद्रित है, डेटाबेस योजना पर नहीं। यह नहीं जानेगा कि:

  • क्या आपकी तालिका या कॉलम नाम आपके डेटाबेस में मौजूद हैं
  • क्या आप संगत डेटा प्रकारों पर जोड़ रहे हैं
  • क्या आपकी क्वेरी अच्छी तरह से कार्य करेगी या इसमें अनुकूलन समस्याएँ हैं
  • क्या आपके पास जिन तालिकाओं को क्वेरी कर रहे हैं, उन्हें एक्सेस करने की अनुमति है

इसे अपने वास्तविक डेटाबेस में क्वेरी भेजने से पहले पहली बार की जाने वाली जाँच के रूप में देखें।

स्वरूपण नियम जो इस टूल द्वारा लागू किए जाते हैं

फॉर्मेटर लगातार नियम लागू करता है जो SQL स्टाइल गाइड सम्मेलनों पर आधारित हैं जिनका अधिकांश डेटाबेस टीमें पालन करती हैं।

कीवर्ड बड़े अक्षरों में लिखे जाते हैं

हर SQL कीवर्ड बड़े अक्षरों में बदल जाता है: SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP। इसमें क्लॉज़ (FROM, WHERE, GROUP BY, HAVING, ORDER BY), जोड़ प्रकार (JOIN, INNER JOIN, LEFT JOIN), ऑपरेटर (AND, OR, NOT, IN, BETWEEN, LIKE), और सामान्य फ़ंक्शन (COUNT, SUM, AVG, CASE, WHEN) शामिल हैं।

बड़े अक्षरों में क्यों? यह SQL के भाषा तत्वों और आपके डेटाबेस-विशिष्ट नामों (टेबल, कॉलम, एलियास) के बीच दृश्य अंतर बनाता है। एक क्वेरी को स्कैन करते समय, आपकी आंख तुरंत संरचना को पहचान लेती है।

प्रत्येक स्तर पर दो-स्पेस इंडेंटेशन

मुख्य क्लॉज़ जैसे SELECT और FROM बाएं मार्जिन पर शुरू होते हैं। JOIN क्लॉज़ FROM के नीचे दो स्पेस इंडेंट होते हैं ताकि दिखाया जा सके कि वे टेबल चयन का हिस्सा हैं। सब-क्वेरी प्रत्येक नेस्टिंग स्तर के लिए अतिरिक्त दो स्पेस इंडेंट होती हैं। यह एक दृश्य पदानुक्रम बनाता है जो तार्किक संरचना से मेल खाता है।

अल्पविराम से अलग की गई सूचियां (उदाहरण के लिए SELECT में कॉलम नाम) प्रत्येक को अपनी पंक्ति में रखा जाता है जिसमें सुसंगत इंडेंटेशन होता है। जब आपके पास SELECT सूची में 15 कॉलम होते हैं, तो यह विशिष्ट कॉलम को स्कैन करना आसान बनाता है।

WHERE क्लॉज़ में शर्तें लंबवत रूप से संरेखित होती हैं। जब आपके पास कई AND या OR शर्तें होती हैं, तो संरेखण तुरंत तार्किक संरचना को स्पष्ट करता है।

पहले और बाद में: अंतर देखें

पहले स्वरूपण:

1select u.id, u.name, o.order_date from users u join orders o on u.id = o.user_id where o.status = "completed" group by u.id order by u.name;
2

बाद स्वरूपण:

1SELECT
2  u.id,
3  u.name,
4  o.order_date
5FROM users u
6  JOIN orders o ON u.id = o.user_id
7WHERE
8  o.status = "completed"
9GROUP BY
10  u.id
11ORDER BY
12  u.name;
13

वैलिडेशन नियम: क्या फ्लैग किया जाता है

वैलिडेटर संरचनात्मक अखंडता और बुनियादी तार्किक सुसंगतता की जाँच करता है। यहाँ वह देखता है:

संरचनात्मक जाँच

संतुलित कोष्ठक: खुलने और बंद होने वाले कोष्ठक को मेल खाना चाहिए। नेस्टेड सबक्वेरी में अक्सर कोष्ठक के कई स्तर होते हैं, और उन्हें गलत गिनना SQL त्रुटियों में सबसे सामान्य है। वैलिडेटर आपके लिए उन्हें गिनता है।

सही ढंग से बंद स्ट्रिंग्स: हर खुलने वाले कोट (एकल या दोहरे) को एक बंद कोट की आवश्यकता होती है। यह स्पष्ट लगता है, लेकिन जब आप बहु स्ट्रिंग लिटरल के साथ एक जटिल क्वेरी लिख रहे होते हैं, तो एक को चूकना आसान है।

सही खंड क्रम: SQL में विशिष्ट क्रम की आवश्यकताएं हैं। SELECT FROM से पहले आता है, जो WHERE से पहले आता है, जो GROUP BY से पहले आता है, जो HAVING से पहले आता है, जो ORDER BY से पहले आता है। उन्हें अनुक्रम से बाहर रखने से तुरंत सिंटैक्स त्रुटियाँ होती हैं। वैलिडेटर SQL मानक के आधार पर इस क्रम की जाँच करता है।

तार्किक सुसंगतता जाँच

ON शर्त के साथ JOIN: हर JOIN को टेबल को संबंधित करने के लिए एक ON या USING खंड की आवश्यकता होती है। इसके बिना, आपको क्रॉस जॉइन मिलता है—एक टेबल की हर पंक्ति दूसरी टेबल की हर पंक्ति के साथ जुड़ी होती है। यह शायद ही कभी वह होता है जो आप चाहते हैं और आमतौर पर एक गायब ON खंड का संकेत देता है।

पूर्ण WHERE शर्तें: WHERE खंड को पूर्ण प्रीडिकेट्स की आवश्यकता होती है। कोई मूल्य के बिना WHERE status = अपूर्ण और अमान्य है। वैलिडेटर इन आंशिक शर्तों को फ्लैग करता है।

HAVING को GROUP BY की आवश्यकता होती है: HAVING खंड समूहीकृत परिणामों को फ़िल्टर करता है, इसलिए यह केवल तभी समझ में आता है जब आपके पास GROUP BY हो। HAVING का उपयोग GROUP BY के बिना एक तार्किक त्रुटि है जिसे अधिकांश डेटाबेस अस्वीकार करते हैं।

GROUP BY एग्रीगेशन नियम: जब आप COUNT() या SUM() जैसे एग्रीगेट फ़ंक्शन का उपयोग करते हैं, तो आपकी SELECT सूची में किसी भी गैर-एग्रीगेट कॉलम को GROUP BY में दिखाया जाना चाहिए। यह एक मौलिक SQL आवश्यकता है जिसकी वैलिडेटर जाँच करता है।

सामान्य त्रुटियों का उदाहरण जो पकड़ी गई हैं

यहाँ SQL है जिसमें कई समस्याएँ हैं जिन्हें वैलिडेटर फ्लैग करेगा:

1SELECT user_id, COUNT(*) FROM orders
2JOIN users
3WHERE status =
4GROUP BY
5HAVING count > 10;
6

पहचानी गई समस्याएँ:

  1. JOIN users में ON शर्त गायब (क्रॉस जॉइन बनाएगा)
  2. WHERE status = अपूर्ण (कोई तुलना मूल्य नहीं)
  3. खाली GROUP BY खंड (कोई कॉलम निर्दिष्ट नहीं)
  4. HAVING count > 10 अपरिभाषित कॉलम का संदर्भ देता है

इस SQL फॉर्मेटर का उपयोग कब करें

कोड समीक्षा के दौरान

क्या आपने कभी एक पंक्ति में लिखी गई 50-लाइन SQL क्वेरी की समीक्षा करने का प्रयास किया है? यह बहुत कठिन होता है। कोड समीक्षा के लिए क्वेरी जमा करने से पहले, उन्हें फॉर्मेटर से गुजारें। आपके समीक्षक आपको धन्यवाद देंगे, और वे वास्तव में तर्क पर ध्यान केंद्रित कर पाएंगे बजाय संरचना को समझने के।

डेटाबेस परिवर्तनों वाली पुल अनुरोधों की समीक्षा करते समय, योगदानकर्ताओं से पहले उनके SQL को फॉर्मेट करने के लिए कहें। जब संरचना सुसंगत होती है तो तर्क त्रुटियों को पहचानना बहुत आसान हो जाता है।

उत्पादन समस्याओं का डीबग करते समय

जब आप उत्पादन में एक विफल क्वेरी का निवारण कर रहे हों, तो उसे उचित रूप से फॉर्मेट करने से आप संरचना को स्पष्ट रूप से देख पाते हैं। मैंने असंख्य क्वेरी का डीबग किया है जहां समस्या तुरंत स्पष्ट हो गई जैसे ही SQL को उचित रूप से फॉर्मेट किया गया—एक गायब जोड़ शर्त, एक गलत WHERE क्लॉज समूहीकरण, या गलत जगह पर एक उप-क्वेरी।

अपने लॉग से क्वेरी कॉपी करें, यहां पेस्ट करें, और आप तुरंत देख पाएंगे कि क्या संरचनात्मक समस्याएं हैं।

जेनरेट किए गए SQL के साथ काम करना

ORMs (ऑब्जेक्ट-रिलेशनल मैपर्स) जैसे Hibernate, Entity Framework, या SQLAlchemy स्वचालित रूप से SQL उत्पन्न करते हैं। कभी-कभी आपको यह देखने की आवश्यकता होती है कि वे वास्तव में किस क्वेरी का उत्पादन कर रहे हैं। जेनरेट किया गया SQL आमतौर पर बिना फॉर्मेटिंग के एक लंबी पंक्ति में होता है। यह टूल ORM द्वारा उत्पन्न क्वेरी को पढ़ने योग्य बनाता है ताकि आप उन्हें समझ और अनुकूलित कर सकें।

SQL सिखाने और सीखने में

यदि आप SQL सीख रहे हैं या सिखा रहे हैं, तो यह फॉर्मेटर आपको उचित क्वेरी संरचना समझने में मदद करता है। जब आप एक कार्यशील क्वेरी पेस्ट करते हैं और देखते हैं कि वह कैसे फॉर्मेट होती है, तो आप परंपराएं सीखते हैं। जब आप एक टूटी हुई क्वेरी पेस्ट करते हैं और सत्यापन त्रुटियां देखते हैं, तो आप समझते हैं कि यह क्यों काम नहीं करती।

डेटाबेस सिस्टम के बीच माइग्रेशन

विभिन्न डेटाबेस (PostgreSQL, MySQL, SQL Server) में थोड़ा अलग SQL बोली होती है। सिस्टम के बीच क्वेरी स्थानांतरित करते समय, उचित फॉर्मेटिंग आपको बोली-विशिष्ट सिंटैक्स को पहचानने में मदद करती है जिसमें समायोजन की आवश्यकता हो सकती है। फॉर्मेटर मानक SQL परंपराओं का पालन करता है जो अधिकांश प्रमुख डेटाबेस में काम करती हैं।

इस SQL फॉर्मेटर के विकल्प

डेटाबेस-विशिष्ट IDEs

DataGrip, SQL सर्वर मैनेजमेंट स्टूडियो, या MySQL वर्कबेंच जैसे टूल्स में अंतर्निहित फॉर्मेटर होते हैं। ये शक्तिशाली होते हैं और सीधे आपके डेटाबेस कनेक्शन के साथ एकीकृत होते हैं।

ट्रेडऑफ: इन्हें इंस्टॉल और सेटअप करने की आवश्यकता होती है। DataGrip व्यक्तिगत उपयोगकर्ताओं के लिए $199/वर्ष में आता है। SSMS मुफ्त है लेकिन केवल Windows के लिए। यदि आपको बिना किसी चीज़ को इंस्टॉल किए त्वरित फॉर्मेटिंग की आवश्यकता है, या आप कई डेटाबेस सिस्टम्स पर काम करते हैं, तो ब्राउज़र-आधारित टूल अधिक व्यावहारिक है।

एडिटर एक्सटेंशन

यदि आप VS कोड या सबलाइम टेक्स्ट में SQL लिखते हैं, तो SQL Beautify या SqlBeautifier जैसे एक्सटेंशन आपके एडिटर में फॉर्मेटिंग लाते हैं। यह तब अच्छी तरह काम करता है जब आप सक्रिय रूप से क्वेरी लिख रहे हैं और अपने कार्यप्रवाह के हिस्से के रूप में तत्काल फॉर्मेटिंग चाहते हैं।

सीमा: एक्सटेंशन को कॉन्फ़िगर करने की आवश्यकता होती है, और वे आपके विशिष्ट एडिटर से जुड़े होते हैं। जब आप SQL को टीम के सदस्यों के साथ साझा करते हैं या दस्तावेज़ीकरण में क्वेरी पोस्ट करते हैं, तो एक मानकीकृत वेब फॉर्मेटर यह सुनिश्चित करता है कि हर कोई एक समान फॉर्मेटिंग देखे।

कमांड-लाइन फॉर्मेटर

sqlformat (Python) या sql-formatter-cli (Node.js) जैसे टूल्स को CI/CD पाइपलाइन में एकीकृत किया जा सकता है ताकि वर्जन नियंत्रण में SQL को स्वचालित रूप से फॉर्मेट किया जा सके। यह एक टीम में निरंतरता सुनिश्चित करता है।

स्वचालित कार्यप्रवाह के लिए सबसे अच्छा उपयोग किया जाता है, न कि तात्कालिक फॉर्मेटिंग के लिए। यदि आप केवल कुछ क्वेरी साफ कर रहे हैं या SQL सीख रहे हैं, तो कमांड-लाइन टूल अनावश्यक जटिलता जोड़ते हैं।

SQL फॉर्मेटिंग कैसे मानक प्रथा बनी

SQL का विकास 1970 के दशक में IBM में हुआ था, लेकिन फॉर्मेटिंग संप्रदाय बहुत बाद में उभरे। प्रारंभिक SQL कार्यात्मक था लेकिन असंगत - हर डेवलपर ने क्वेरी को अलग-अलग तरीके से फॉर्मेट किया।

मोड़ 1990 के दशक में आया जब डेटाबेस एकल-डेवलपर परियोजनाओं से टीम-आधारित विकास में बदल गए। संगठनों ने सुसंगतता बनाए रखने के लिए आंतरिक SQL स्टाइल गाइड बनाना शुरू किया। जब पांच डेवलपर एक ही डेटाबेस पर काम कर रहे थे, तो पठनीय SQL सहयोग के लिए आवश्यक हो गया।

2000 के दशक में ORMs आए जो स्वचालित रूप से SQL उत्पन्न करते थे। इन टूल्स ने काम करने वाला लेकिन बदसूरत SQL उत्पन्न किया - सब कुछ एक पंक्ति में, कोई इंडेंटेशन नहीं। इसने स्वचालित फॉर्मेटर की मांग पैदा की जो उत्पन्न SQL को मानव-पठनीय बना सकें।

2010 के दशक में वेब विकास के परिपक्व होने के साथ ऑनलाइन SQL फॉर्मेटर दिखाई दिए। टूल्स इंस्टॉल करने या IDE प्लगइन कॉन्फ़िगर करने के बजाय, डेवलपर ब्राउज़र में SQL फॉर्मेट कर सकते थे। इसने शुरुआती SQL सीखने वालों से लेकर अनुभवी डेवलपर्स तक सभी के लिए उचित फॉर्मेटिंग तक पहुंच को लोकतांत्रिक बना दिया।

आज, SQL फॉर्मेटिंग को अन्य प्रोग्रामिंग भाषाओं में कोड फॉर्मेटिंग के समान एक बेसलाइन प्रथा माना जाता है। साइमन होलीवेल द्वारा SQL स्टाइल गाइड व्यापक रूप से अपनाई गई परंपराएं प्रदान करता है, और ऐसे टूल्स इन मानकों को स्वचालित रूप से लागू करते हैं।

कोड उदाहरण

उदाहरण 1: बेसिक SELECT क्वेरी

अस्वरूपित:

1select id, first_name, last_name, email from customers where status = 'active' order by last_name, first_name;
2

स्वरूपित:

1SELECT
2  id,
3  first_name,
4  last_name,
5  email
6FROM
7  customers
8WHERE
9  status = 'active'
10ORDER BY
11  last_name,
12  first_name;
13

उदाहरण 2: JOIN क्वेरी

अस्वरूपित:

1select c.id, c.name, o.order_date, o.total_amount from customers c left join orders o on c.id = o.customer_id where o.order_date >= '2023-01-01' and o.status != 'cancelled' order by o.order_date desc;
2

स्वरूपित:

1SELECT
2  c.id,
3  c.name,
4  o.order_date,
5  o.total_amount
6FROM
7  customers c
8  LEFT JOIN orders o ON c.id = o.customer_id
9WHERE
10  o.order_date >= '2023-01-01'
11  AND o.status != 'cancelled'
12ORDER BY
13  o.order_date DESC;
14

उदाहरण 3: सबक्वेरी के साथ जटिल क्वेरी

अस्वरूपित:

1select d.department_name, (select count(*) from employees e where e.department_id = d.id) as employee_count, (select avg(salary) from employees e where e.department_id = d.id) as avg_salary from departments d where d.active = true having employee_count > 0 order by avg_salary desc;
2

स्वरूपित:

1SELECT
2  d.department_name,
3  (
4    SELECT
5      COUNT(*)
6    FROM
7      employees e
8    WHERE
9      e.department_id = d.id
10  ) AS employee_count,
11  (
12    SELECT
13      AVG(salary)
14    FROM
15      employees e
16    WHERE
17      e.department_id = d.id
18  ) AS avg_salary
19FROM
20  departments d
21WHERE
22  d.active = TRUE
23HAVING
24  employee_count > 0
25ORDER BY
26  avg_salary DESC;
27

प्रोग्रामेटिक SQL स्वरूपण

यहाँ विभिन्न प्रोग्रामिंग भाषाओं में SQL स्वरूपण के उदाहरण हैं:

1// JavaScript SQL स्वरूपण उदाहरण sql-formatter लाइब्रेरी का उपयोग करते हुए
2const sqlFormatter = require('sql-formatter');
3
4function formatSQL(sql) {
5  return sqlFormatter.format(sql, {
6    language: 'sql',
7    uppercase: true,
8    linesBetweenQueries: 2,
9    indentStyle: 'standard'
10  });
11}
12
13const rawSQL = "select id, name from users where status='active'";
14const formattedSQL = formatSQL(rawSQL);
15console.log(formattedSQL);
16

अक्सर पूछे जाने वाले प्रश्न

क्या यह SQL फॉर्मेटर PostgreSQL, MySQL और SQL Server के साथ काम करता है?

हाँ, यह मुख्य डेटाबेस में सामान्य SQL सिंटैक्स को संभालता है—PostgreSQL, MySQL, SQL Server (T-SQL), Oracle, SQLite, और MariaDB। फॉर्मेटर मूल SQL पर केंद्रित है जो हर जगह काम करता है: SELECT, JOIN, WHERE, GROUP BY, आदि।

डेटाबेस-विशिष्ट सुविधाएँ शायद पूरी तरह से फॉर्मेट न हों। उदाहरण के लिए, PostgreSQL का एरे सिंटैक्स या SQL Server के विशेष फ़ंक्शन विशेष फॉर्मेटिंग उपचार नहीं पा सकते, लेकिन वे फॉर्मेटर को नहीं तोड़ेंगे। क्वेरी फिर भी पहले से अधिक पठनीय होगी।

क्या मेरा SQL कोड सर्वर पर भेजा जाता है?

नहीं। सब कुछ आपके ब्राउज़र में होता है। अपना SQL पेस्ट करें, और यह स्थानीय रूप से बिना किसी नेटवर्क अनुरोध के फॉर्मेट हो जाएगा। आपकी क्वेरी कभी आपकी मशीन से बाहर नहीं जाती।

यह तब महत्वपूर्ण होता है जब आप उत्पादन डेटाबेस योजनाओं या गोपनीय व्यावसायिक तर्क के साथ काम कर रहे होते हैं। संवेदनशील जानकारी के लॉग या संग्रहित होने का कोई जोखिम नहीं है।

क्या वैलिडेटर सभी SQL त्रुटियों को पकड़ सकता है?

बिल्कुल नहीं। यह संरचनात्मक और सिंटैक्स मुद्दों को पकड़ता है—गुम कोष्ठक, बंद न किए गए उद्धरण, गलत क्रम में खंड। बस इतना।

यह नहीं जानेगा कि आपके टेबल नाम गलत हैं, डेटा प्रकार असंगत हैं, या आपकी क्वेरी 10 मिनट चलेगी। उसके लिए, आपको अपना वास्तविक डेटाबेस चाहिए। इस वैलिडेटर को SQL के लिए स्पेल-चेक के रूप में सोचें, पूर्ण क्वेरी विश्लेषक के रूप में नहीं।

SQL को फॉर्मेट करने का क्या फायदा जब मेरा डेटाबेस इसे फिर भी चलाता है?

डेटाबेस फॉर्मेटिंग की परवाह नहीं करते—वे क्वेरी को फिर भी पार्स करते हैं। लेकिन मनुष्य परवाह करते हैं। जब आपको एक विफल क्वेरी को डीबग करना होता है, मौजूदा को संशोधित करना होता है, या किसी और के SQL की समीक्षा करनी होती है, तो उचित फॉर्मेटिंग 30 सेकंड बनाम 30 मिनट में समझने का अंतर करती है।

फॉर्मेटेड SQL आपको तर्क त्रुटियों को भी पकड़ने में मदद करता है। जब संरचना स्पष्ट होती है, तो आप देख सकते हैं कि क्या आपने टेबल को गलत तरीके से जोड़ा है या शर्तों को गलत जगह रखा है।

क्या मैं इंडेंटेशन या कीवर्ड शैली को अनुकूलित कर सकता हूँ?

वर्तमान में नहीं। फॉर्मेटर मानक परंपराओं का उपयोग करता है: अपरकेस कीवर्ड, दो-स्पेस इंडेंटेशन, अलग-अलग पंक्तियों पर खंड। ये SQL स्टाइल गाइड का पालन करते हैं जिसका अधिकांश टीमें उपयोग करती हैं।

यदि आपको कस्टम फॉर्मेटिंग की आवश्यकता है (अलग इंडेंटेशन चौड़ाई, लोअरकेस कीवर्ड), तो आपको एक कॉन्फ़िगर करने योग्य कमांड-लाइन टूल जैसे sqlformat या फॉर्मेटिंग सेटिंग्स वाले एक IDE की आवश्यकता होगी।

क्या यह 1000-लाइन स्टोर्ड प्रोसीजर के साथ काम करेगा?

यह बड़ी क्वेरी को फॉर्मेट करेगा, हालांकि बहुत जटिल स्टोर्ड प्रोसीजर (1000+ लाइन) को प्रोसेस करने में कुछ सेकंड लग सकते हैं। फॉर्मेटर आपके द्वारा पेस्ट किए गए SQL को संभालता है, चाहे लंबाई कुछ भी हो।

विशाल स्टोर्ड प्रोसीजर के लिए, आप उन्हें छोटे टुकड़ों में विभाजित करना चाह सकते हैं या एक डेटाबेस-विशिष्ट IDE का उपयोग कर सकते हैं जो बड़ी फ़ाइलों के लिए अनुकूलित है।

क्या फॉर्मेटिंग मेरी क्वेरी के निष्पादन को बदलती है?

नहीं। फॉर्मेटिंग केवल व्हाइटस्पेस जोड़ती है और पूंजीकरण बदलती है। आपका डेटाबेस दोनों को नजरअंदाज करता है। फॉर्मेटेड क्वेरी बिल्कुल वही परिणाम देती है और उसी प्रदर्शन के साथ चलती है जैसा कि अनफॉर्मेटेड संस्करण।

एकमात्र अपवाद: यदि वैलिडेटर वास्तविक सिंटैक्स त्रुटियाँ पाता है (गुम कोष्ठक, आदि), तो उन्हें ठीक करने से व्यवहार बदलेगा—लेकिन केवल "नहीं चलता" से "सही ढंग से चलता" तक।

यह किस SQL मानक का पालन करता है?

फॉर्मेटर SQL-92 परंपराओं का पालन करता है SQL:1999 और बाद के मानकों की सामान्य सुविधाओं के साथ। यह वह SQL को कवर करता है जो अधिकांश डेवलपर रोजाना लिखते हैं—SELECT क्वेरी, जॉइन, सब-क्वेरी, CASE स्टेटमेंट, विंडो फ़ंक्शन।

SQL:2016 या SQL:2019 से बहुत नई SQL सुविधाएँ पहचानी नहीं जा सकती हैं, लेकिन वे फॉर्मेटर को नहीं तोड़ेंगी। आपको बस बुनियादी फॉर्मेटिंग मिलेगी बजाय विशेष हैंडलिंग के।

क्या मैं इसका उपयोग Oracle PL/SQL या SQL Server T-SQL के लिए कर सकता हूँ?

बुनियादी क्वेरी के लिए, हाँ। प्रक्रियात्मक कोड (PL/SQL ब्लॉक, नियंत्रण प्रवाह के साथ T-SQL स्टोर्ड प्रोसीजर) के लिए, फॉर्मेटिंग सीमित होगी। टूल SELECT, INSERT, UPDATE, DELETE स्टेटमेंट और उनके खंडों पर केंद्रित है।

यदि आप गहराई से डेटाबेस-विशिष्ट प्रक्रियात्मक कोड के साथ काम कर रहे हैं, तो आपके डेटाबेस के मूल IDE (Oracle के लिए SQL Developer, SQL Server के लिए SSMS) बेहतर फॉर्मेटिंग प्रदान करेंगे जो पूर्ण सिंटैक्स को समझता है।

संदर्भ और अधिक पढ़ने के लिए

अपने SQL को फॉर्मेट करना शुरू करें

पढ़ने योग्य SQL डीबगिंग को तेज, कोड समीक्षा को आसान और सहयोग को सुचारु बनाता है। अपने क्वेरी को ऊपर पेस्ट करें ताकि उसे उद्योग-मानक मानदंडों के अनुसार फॉर्मेट किया जा सके—कोई इंस्टॉलेशन नहीं, कोई कॉन्फ़िगरेशन नहीं, कोई डेटा आपके ब्राउज़र से बाहर नहीं जाएगा।