मुफ़्त SQL फ़ॉर्मेटर

कस्टमाइज़ करने योग्य इंडेंटेशन और कीवर्ड केसिंग के साथ SQL क्वेरी को फ़ॉर्मेट और सुंदर करें।

SQL फ़ॉर्मेटिंग वास्तव में क्या करती है

SQL पार्स के समय वाइटस्पेस-असंवेदनशील है, हर डेटाबेस इंजन SELECT name,age FROM users WHERE active=1 को मल्टी-लाइन इंडेंटेड फ़ॉर्म के समान ही पढ़ता है। दृश्य अंतर पूरी तरह से मानव पाठकों के लिए है। एक फ़ॉर्मेटर एक टोकनाइज़र के माध्यम से SQL पढ़ता है जो कीवर्ड्स, आइडेंटिफ़ायर्स, लिटरल्स, ऑपरेटर्स और विराम चिह्न पहचानता है, फिर उसी क्वेरी को पारंपरिक इंडेंटेशन, क्लॉज़ों के बीच लाइन ब्रेक्स, सामान्यीकृत कीवर्ड केस, और ऑपरेटर्स के चारों ओर सुसंगत स्पेसिंग के साथ फिर से उत्सर्जित करता है। डेटा सिमेंटिक्स अपरिवर्तित हैं (फ़ॉर्मेटेड क्वेरी चलाने से समान परिणाम मिलते हैं) लेकिन 200-लाइन की एनालिटिक्स क्वेरी पर पठनीयता का अंतर "मैं इसे डिबग कर सकता हूँ" और "मैं बस इसे शुरू से फिर से लिखूँगा" के बीच का अंतर है।

SQL, जिस भाषा को फ़ॉर्मेट किया जा रहा है उसका संक्षिप्त इतिहास

SQL (Structured Query Language) IBM में Donald D. Chamberlin और Raymond F. Boyce द्वारा 1970 के दशक की शुरुआत में विकसित की गई, मूल रूप से SEQUEL ("Structured English Query Language") के रूप में, ट्रेडमार्क संघर्ष के बाद SQL नाम दिया गया। भाषा को पहली बार 1979 में Oracle के पूर्ववर्ती (Relational Software, Inc.) द्वारा व्यावसायिक बनाया गया, Oracle V2 पहला व्यावसायिक SQL डेटाबेस था, जो IBM के अपने DB2 से पहले बाज़ार में आया। पहला ANSI मानक, ANSI SQL-86, 1986 में प्रकाशित हुआ; बहुत अधिक मूल संशोधन SQL-92 ("बड़ा" SQL मानक, ISO/IEC 9075:1992) ने अधिकांश सिंटैक्स को परिभाषित किया जिसे आधुनिक उपयोगकर्ता पहचानते हैं, JOIN सिंटैक्स, सेट संचालन, सबक्वेरी, ट्रांज़ैक्शन। बाद के संशोधनों ने ऑब्जेक्ट-रिलेशनल फ़ीचर्स (SQL:1999), XML समर्थन (SQL:2003), विंडो फ़ंक्शन और CTE (SQL:2003 और 2008), टेम्पोरल क्वेरीज़ (SQL:2011), JSON समर्थन (SQL:2016, SQL:2023 में विस्तारित) जोड़े। हर प्रमुख डेटाबेस वेंडर अपनी डायलेक्ट लागू करता है, MySQL, PostgreSQL, SQLite, Microsoft SQL Server (T-SQL), Oracle (PL/SQL), DuckDB (PostgreSQL-संगत एनालिटिक SQL), BigQuery, Snowflake, Redshift, ClickHouse, Databricks SQL: सभी SQL-92 कोर साझा करते हैं लेकिन फ़ंक्शन्स, सिंटैक्स विस्तार और रिज़र्व्ड शब्द सूचियों में भिन्न होते हैं। एक अच्छा फ़ॉर्मेटर उस डायलेक्ट का सम्मान करता है जिसे वह फ़ॉर्मेट कर रहा है क्योंकि एक ही आइडेंटिफ़ायर एक डायलेक्ट में कीवर्ड और दूसरे में वैध कॉलम नाम हो सकता है।

वे परंपराएँ जो SQL को पठनीय बनाती हैं

SQL स्टाइल गाइड्स में कई परंपराएँ मानक बन गई हैं, Mozilla की, Simon Holywell का व्यापक रूप से उद्धृत SQL Style Guide, GitLab की डेटा टीम की परंपराएँ, dbt की अनुशंसित शैली। UPPERCASE में कीवर्ड्स (SELECT, FROM, WHERE, JOIN) बनाम लोअरकेस या snake_case में आइडेंटिफ़ायर्स (टेबल और कॉलम नाम) प्रमुख परंपरा है। कुछ स्टाइल गाइड्स विपरीत की वकालत करती हैं (लोअरकेस कीवर्ड्स टाइप और पढ़ने में आसान हैं), और PostgreSQL की अपनी डायलेक्ट डॉक्यूमेंटेशन पूरी तरह लोअरकेस कीवर्ड्स का उपयोग करती है, लेकिन UPPERCASE कीवर्ड्स अधिकांश पेशेवर कोडबेस में जीतते हैं क्योंकि वे भाषा संरचना को एक नज़र में दृश्यमान बनाते हैं। हर मुख्य क्लॉज़ अपनी अलग लाइन पर: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, हर एक उसी इंडेंट स्तर पर एक नई लाइन शुरू करता है। JOIN शर्तें ON के नीचे इंडेंटेड: JOIN कीवर्ड अपनी लाइन पर, ON कीवर्ड अगली लाइन पर एक स्तर इंडेंटेड। कॉमा-पहले या कॉमा-बाद कॉलम सूचियों में एक दीर्घकालिक शैली बहस है; कॉमा-पहले (हर कॉलम लाइन कॉमा से शुरू होती है) कॉलम जोड़ने/हटाने पर साफ़ डिफ़्स बनाती है और ट्रेलिंग-कॉमा सिंटैक्स त्रुटि से बचाती है, लेकिन कई लोगों को दृष्टिगत रूप से असामान्य लगती है। कॉमा-बाद प्रोडक्शन कोड में अधिक सामान्य है। सबक्वेरी इंडेंटेशन: नेस्टेड क्वेरीज़ अपने पैरेंट से एक स्तर गहरी इंडेंटेड। CTE (WITH) क्लॉज़: हर नामित CTE अपनी अलग लाइन पर, बॉडी AS के नीचे इंडेंटेड, मुख्य क्वेरी सबसे नीचे बाएँ संरेखित।

जब आप SQL फ़ॉर्मेटर के लिए पहुँचेंगे

SQL फ़ॉर्मेटर का इकोसिस्टम

कमांड-लाइन और एडिटर-एकीकृत वर्कफ़्लो के लिए, कई परिपक्व विकल्प मौजूद हैं। sql-formatter (npm पैकेज, मूल रूप से Andriy Isayev द्वारा, अब एक समुदाय टीम द्वारा अनुरक्षित) JavaScript-इकोसिस्टम का प्रमुख SQL फ़ॉर्मेटर है, MySQL, PostgreSQL, SQLite, Standard SQL, BigQuery, Redshift, Snowflake, Spark, TiDB, MariaDB और कई अन्य डायलेक्ट्स का समर्थन करता है। pg_format (Gilles Darold) कैनोनिकल PostgreSQL-विशिष्ट फ़ॉर्मेटर है, Perl में लिखा गया और लोकप्रिय pgFormatter वेब सेवा के साथ बंडल किया गया। Poor Man's T-SQL Formatter (Tao Klerks, 2011) Microsoft SQL Server के T-SQL डायलेक्ट को विशेष रूप से लक्षित करता है। sqlparse (Andi Albrecht) मानक Python लाइब्रेरी है, जो Django द्वारा क्वेरी विश्लेषण के लिए और अनगिनत डेटा-इंजीनियरिंग स्क्रिप्ट्स द्वारा उपयोग की जाती है। SQLFluff आधुनिक लिंटर-और-फ़ॉर्मेटर है जो dbt प्रोजेक्ट्स और एनालिटिक्स वर्कफ़्लो के साथ एकीकृत होता है। JetBrains के DataGrip और IntelliJ IDEA के लिए SQL प्लगइन में एक परिष्कृत डायलेक्ट-जागरूक फ़ॉर्मेटर शामिल है; VS Code के SQLTools और कई अन्य एक्सटेंशन npm sql-formatter लाइब्रेरी को लपेटते हैं। बिल्ड पाइपलाइन वाले प्रोजेक्ट्स के लिए, आधुनिक पैटर्न "एडिटर में सेव पर फ़ॉर्मेट + एक CI चेक जो SQL फ़ाइलों के ग़लत-फ़ॉर्मेट होने पर बिल्ड फेल कर देता है" है, JavaScript के लिए Prettier या Python के लिए Black का समान मॉडल।

डायलेक्ट अंतर जो फ़ॉर्मेटिंग के लिए मायने रखते हैं

अधिकांश SQL फ़ॉर्मेटर्स छोटे समायोजन के साथ डायलेक्ट्स के पार काम करते हैं, लेकिन मुट्ठी भर अंतर के लिए फ़ॉर्मेटर को यह जानना आवश्यक है कि वह कौन सा डायलेक्ट पढ़ रहा है। उद्धरण चिह्नित आइडेंटिफ़ायर्स: मानक SQL दोहरे उद्धरण ("order") का उपयोग करता है; MySQL डिफ़ॉल्ट रूप से बैकटिक्स (`order`) का उपयोग करता है और केवल ANSI मोड में दोहरे उद्धरणों का सम्मान करता है; SQL Server वर्ग कोष्ठक ([order]) का उपयोग करता है। स्ट्रिंग संयोजन: मानक SQL || का उपयोग करता है; MySQL CONCAT() या ANSI मोड में दुर्लभ-दिखाई देने वाले || का उपयोग करता है; SQL Server + का उपयोग करता है। पेजिनेशन: MySQL/PostgreSQL/SQLite LIMIT/OFFSET का उपयोग करते हैं; SQL Server TOP या OFFSET FETCH का उपयोग करता है; Oracle FETCH या ROWNUM का उपयोग करता है। ऑटो-इन्क्रीमेंट: MySQL में AUTO_INCREMENT, PostgreSQL में SERIAL या IDENTITY, SQL Server में IDENTITY, SQLite में AUTOINCREMENT। रिज़र्व्ड शब्द सूचियाँ भिन्न होती हैं, rank नामक कॉलम को PostgreSQL में उद्धरण की आवश्यकता होती है (जहाँ RANK विंडो फ़ंक्शन कीवर्ड है) लेकिन MySQL में आइडेंटिफ़ायर के रूप में ठीक है। एक फ़ॉर्मेटर जो डायलेक्ट नहीं जानता वह अनुपयुक्त उद्धरण जोड़कर वैध क्वेरीज़ को तोड़ सकता है। एक सामान्य फ़ॉर्मेटर से "Format SQL" आउटपुट आमतौर पर मानक SELECT/INSERT/UPDATE/DELETE आकार के लिए सही होता है; वेंडर-विशिष्ट सिंटैक्स (विंडो फ़ंक्शन, हिंट्स, सिस्टम फ़ंक्शन) के लिए, अपने डायलेक्ट डॉक्स के विरुद्ध आउटपुट की जाँच करें।

गोपनीयता: ब्राउज़र-केवल SQL के लिए विशेष रूप से क्यों मायने रखता है

SQL क्वेरीज़ किसी भी संगठन में सबसे संवेदनशील पाठों में से कुछ हैं: वे आंतरिक टेबल नाम (जो उत्पाद वर्गीकरण प्रकट करते हैं), कॉलम नाम (जो डेटा मॉडल प्रकट करते हैं), फ़िल्टर मान (जिनमें वास्तविक उपयोगकर्ता ID, ईमेल पते, व्यवसाय ID शामिल हो सकते हैं), पुराने पैटर्न में एम्बेडेड शाब्दिक क्रेडेंशियल्स, और एनालिटिक्स की संरचना जिसे कंपनी मालिकाना मान सकती है, उजागर करते हैं। सर्वर-साइड SQL फ़ॉर्मेटर्स अपने लॉग्स में हर क्वेरी की एक प्रति लेते हैं। यह फ़ॉर्मेटर आपके ब्राउज़र में पूरी तरह से JavaScript के माध्यम से चलता है, DevTools के नेटवर्क टैब में सत्यापित करें जब आप Format पर क्लिक करते हैं (कोई अनुरोध फ़ायर नहीं होता), या लोड होने के बाद पृष्ठ को ऑफ़लाइन (हवाई जहाज मोड) करें और फ़ॉर्मेटर अभी भी काम करता है। वास्तविक टेबल नाम और PII फ़िल्टर मान वाली प्रोडक्शन क्वेरीज़, आंतरिक एनालिटिक SQL, ETL पाइपलाइन, या किसी भी क्वेरी के लिए सुरक्षित जिसे आप किसी अजनबी की हार्ड ड्राइव पर कॉपी होते नहीं देखना चाहेंगे।

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

क्या फ़ॉर्मेटर SQL कीवर्ड्स को स्वचालित रूप से UPPERCASE कर सकता है?

हाँ, Keywords टॉगल केस को नियंत्रित करता है। UPPERCASE प्रमुख पेशेवर परंपरा है क्योंकि यह भाषा संरचना को एक नज़र में दृश्यमान बनाती है (SELECT, FROM, WHERE आइडेंटिफ़ायर्स से अलग दिखते हैं); लोअरकेस कुछ स्टाइल गाइड्स द्वारा पसंद किया जाता है (PostgreSQL की अपनी डॉक्यूमेंटेशन पूरी तरह लोअरकेस का उपयोग करती है) इस आधार पर कि यह पढ़ने में आसान और टाइप करने में तेज़ है। दोनों काम करते हैं जब तक कि आपकी टीम एक चुनती है और इसे सुसंगत रूप से उपयोग करती है। कैपिटलाइज़ेशन का क्वेरी व्यवहार पर कोई प्रभाव नहीं पड़ता, SQL कीवर्ड्स पार्स के समय केस-असंवेदनशील हैं।

मैं इंडेंटेशन को कैसे अनुकूलित करूँ?

Indent ड्रॉपडाउन 2 स्पेस (प्रमुख आधुनिक वेब परंपरा), 4 स्पेस (पुराने Java और .NET शॉप्स में अभी भी सामान्य), या टैब वर्णों का समर्थन करता है। 2 स्पेस नई कोडबेस में जीतते हैं और SQL के लिए विशेष रूप से क्योंकि गहरी सबक्वेरी नेस्टिंग 100-वर्ण लाइन सीमा के भीतर अधिक आराम से फिट होती है। जो भी परंपरा आपकी टीम पहले से ही उपयोग करती है उससे मेल खाएँ; विशिष्ट विकल्प की तुलना में संगति अधिक मायने रखती है।

क्या यह बड़ी क्वेरीज़ के साथ काम करता है?

हाँ, चूँकि फ़ॉर्मेटिंग आपके ब्राउज़र में चलती है, व्यावहारिक छत आपके डिवाइस की उपलब्ध मेमोरी है। SQL की सैकड़ों लाइनें एक सेकंड से बहुत कम में फ़ॉर्मेट हो जाती हैं; कई-हज़ार-लाइन क्वेरीज़ (डेटा-वेयरहाउस ETL में विशिष्ट) काम करती हैं लेकिन पार्सर के संरचना से चलने के दौरान टैब को संक्षेप में फ़्रीज़ कर सकती हैं। पूरे SQL रिपॉज़िटरी के बैच पुनः-फ़ॉर्मेटिंग के लिए, कमांड-लाइन उपकरण (npm के माध्यम से sql-formatter, PostgreSQL के लिए pg_format, dbt प्रोजेक्ट्स के लिए SQLFluff) अधिक उपयुक्त हैं।

क्या फ़ॉर्मेटर मेरे विशिष्ट SQL डायलेक्ट को पहचानेगा?

यह MySQL, PostgreSQL, SQLite, T-SQL और मानक ANSI SQL में सामान्य SELECT/INSERT/UPDATE/DELETE/JOIN/CTE/सबक्वेरी आकारों को सही ढंग से संभालता है। वेंडर-विशिष्ट सिंटैक्स (विंडो-फ़ंक्शन क्लॉज़, MERGE स्टेटमेंट, डायलेक्ट-विशिष्ट हिंट्स, सिस्टम फ़ंक्शन, PostgreSQL-शैली ऐरे ऑपरेटर, T-SQL XML विधियाँ) अपूर्ण रूप से फ़ॉर्मेट हो सकता है। आउटपुट की स्पॉट-जाँच करें और कमिट करने से पहले यह पुष्टि करने के लिए कि यह सही पार्स करता है, फ़ॉर्मेटेड क्वेरी को अपने डेटाबेस से चलाएँ।

क्या मेरा SQL अपलोड किया जाता है?

नहीं। फ़ॉर्मेटिंग आपके ब्राउज़र में पूरी तरह से चलती है, पेस्ट की गई क्वेरीज़ कभी आपका डिवाइस नहीं छोड़तीं। DevTools के नेटवर्क टैब में सत्यापित करें जब आप Format पर क्लिक करते हैं (कोई अनुरोध फ़ायर नहीं होता), या लोड होने के बाद पृष्ठ को ऑफ़लाइन (हवाई जहाज मोड) करें। संवेदनशील टेबल नाम, PII फ़िल्टर मान, या NDA या अनुपालन विनियमन द्वारा कवर किए गए किसी भी SQL वाली प्रोडक्शन क्वेरीज़ के लिए सुरक्षित।

संबंधित टूल