SQL क्वेरी फॉर्मेट करा _

SQL फॉर्मेटिंग कसे कार्य करते

SQL फॉर्मेटिंग ही एक lexer-driven पुनर्लेखन प्रक्रिया आहे जी क्वेरीतील प्रत्येक टोकनमधून जाते आणि निवडलेल्या डायलेक्टच्या नियमांनुसार त्याभोवती whitespace पुन्हा उत्सर्जित करते. क्वेरीचा अर्थ कधीच बदलत नाही — केवळ मांडणी बदलते.

1. डायलेक्ट निवडा. MySQL backticks, PostgreSQL :: casts, BigQuery dotted table paths आणि T-SQL square-bracket identifiers — प्रत्येकाला त्यांना ओळखणारा tokenizer लागतो. डायलेक्ट निवडकर्ता कोणते व्याकरण लागू करायचे ते ठरवतो.
2. इनपुट Tokenize करा. फॉर्मेटर क्वेरीला टोकन्सच्या प्रवाहात विभाजित करतो: keywords (SELECT, JOIN), identifiers, literals, operators, parentheses आणि comments. String literals आणि quoted identifiers अपरिवर्तित पाठवले जातात.
3. Layout नियम लागू करा. Top-level clauses (SELECT, FROM, WHERE, GROUP BY, ORDER BY) स्वतःच्या ओळींवर सुरू होतात. Select list आणि column lists मधील comma-separated expressions प्रत्येकी एका ओळीवर, निवडलेल्या indent unit ने आत घेतलेल्या.
4. Keyword Case लागू करा. Keyword-case toggle ओळखलेल्या SQL keywords ना uppercase, lowercase मध्ये पुनर्लेखित करतो किंवा इनपुट casing तसाच ठेवतो. Identifiers कधीच बदलत नाहीत — column आणि table नावे नेहमी जशी लिहिली तशीच येतात.
5. फॉर्मेट केलेली String उत्सर्जित करा. टोकन प्रवाह indent character (2 spaces, 4 spaces किंवा tab) आणि configured linebreak नियमासह एका string मध्ये जोडला जातो. लाइव्ह मोड टाइप करताना 200 ms debounce वर संपूर्ण पाइपलाइन पुन्हा चालवतो.

SQL प्रिटी-प्रिंट का करावे

• Pull-request diff वाचनीयता. 200-ओळींचा CTE एकाच ओळीत पुनर्लेखित केल्याने code review अनुमानाचा खेळ बनतो. सुसंगत फॉर्मेटिंग diff ला खऱ्या बदलापुरती मर्यादित ठेवते — नवीन column, अतिरिक्त JOIN, वेगळा WHERE predicate — reviewer whitespace न उलगडता पाहू शकतो.
• debugging सोपे होते. जेव्हा क्वेरी चुकीचा row count देते, तेव्हा पहिले काम ती ओळ-दर-ओळ वाचणे. Formatted SQL प्रत्येक JOIN स्वतःच्या ओळीवर ठेवते आणि WHERE predicates रांगेत मांडते, ज्यामुळे चुकलेला AND किंवा भरकटलेला OR एका नजरेत दिसतो.
• टीम शैली सुसंगत. बहुतेक टीम्स SQL style guide स्वीकारतात (dbt Labs, GitLab, Mode Analytics सर्वांनी त्यांच्या प्रकाशित केल्या आहेत) आणि प्रत्येक committed क्वेरी त्याचे पालन करावी असे वाटते. Commit आधी फॉर्मेटर चालवल्याने review मधून शैली-वाद निघून जातो आणि फक्त तर्कशास्त्रावर चर्चा उरते.
• Docs मध्ये SQL शेअर करणे. Runbooks, incident retros आणि Notion docs सर्वांना वरून खाली वाचता येणाऱ्या SQL चा फायदा होतो. Formatted SQL fenced code block मध्ये नीट पेस्ट होते आणि PDF exports मध्ये अंदाजानुसार मुद्रित होते, mid-keyword awkward ओळ गुंडाळणी नाही.

सामान्य उपयोग

SQL फॉर्मेटिंग analytics engineering, backend development आणि operations कामात सर्वत्र दिसते जेव्हा एखादी क्वेरी ज्याने लिहिली नाही त्याला वाचायची असते.

• Analytics engineering: dbt प्रकल्पातील pre-commit hook जो प्रत्येक model file पुन्हा फॉर्मेट करतो जेणेकरून PR diffs logic बदलांपुरते मर्यादित राहतात, whitespace churn नाही.
• Database administration: एकाच ओळीची slow-query log नोंद पेस्ट करा, फॉर्मेट करा आणि incident retro लिहिताना join order पहा.
• Documentation: Looker explore किंवा Tableau workbook मधून क्वेरी घ्या, runbook साठी फॉर्मेट करा आणि on-call rotation साठी copy-pasteable उदाहरण म्हणून एम्बेड करा.

एक व्यावहारिक उदाहरण

SELECT u.id,u.email,COUNT(o.id) FROM users u LEFT JOIN orders o ON o.user_id=u.id WHERE u.created_at > '2024-01-01' GROUP BY u.id,u.email ORDER BY u.id; इनपुट pane मध्ये पेस्ट करा, dialect PostgreSQL, indent 2 spaces आणि keyword case UPPER सेट करा. आउटपुट SELECT, FROM, LEFT JOIN, WHERE, GROUP BY आणि ORDER BY स्वतःच्या ओळींवर ठेवते; select list आणि group-by list मधील प्रत्येक column स्वतःच्या indented ओळीवर; आणि ON predicate त्याच्या JOIN keyword पेक्षा एक indent खोल.

FAQ

कोणते SQL dialects समर्थित आहेत?

Dialect dropdown मध्ये Standard SQL, MySQL, PostgreSQL, SQLite, MariaDB, Transact-SQL (SQL Server / Azure SQL), BigQuery, Snowflake आणि Redshift समाविष्ट आहे. अंतर्गत sql-formatter library DuckDB, Spark SQL, Hive, Trino, Db2, N1QL, PL/SQL, ClickHouse, TiDB आणि SingleStoreDB देखील ओळखते — सर्वात जवळचा dialect निवडल्याने अचूक target नसतानाही योग्य आउटपुट मिळते. Identifiers, string literals आणि dialect-specific operators (PostgreSQL @>, BigQuery SAFE. prefixes) verbatim ठेवले जातात.

हे माझी SQL validate करते का?

नाही. फॉर्मेटर एक lexical rewriter आहे, parser नाही. ते इनपुट tokenize करते, layout नियम लागू करते आणि परिणाम उत्सर्जित करते; क्वेरी semantically valid आहे का, referenced tables अस्तित्वात आहेत का, किंवा निवडलेल्या dialect मध्ये syntax कायदेशीर आहे का हे तपासत नाही. खऱ्या accuracy तपासणीसाठी formatted आउटपुट actual database (किंवा SQLFluff सारख्या SQL linter) मधून चालवा.

माझे keywords uppercase का होत आहेत?

Keyword case dropdown चे default UPPER आहे, जे बहुतेक प्रकाशित SQL style guides (dbt Labs, Mode, GitLab) चे convention आहे. तुमची टीम select / from lowercase लिहित असेल तर lower निवडा, किंवा तुम्हाला तुमची casing ठेवायची असेल तर Preserve निवडा. Identifiers कधीच प्रभावित होत नाहीत — केवळ ओळखलेला keyword संच पुनर्लेखित होतो.

माझी क्वेरी कुठे upload होते का?

नाही. Vendored sql-formatter library तुमच्या ब्राउझरमध्ये चालते, फॉर्मेटिंग तुमच्या machine वर स्थानिक पातळीवर होते आणि query text नेटवर्कवर पाठवले जात नाही. या पानाच्या एकमेव outbound requests म्हणजे tools.ultim8soft.com च्या प्रत्येक पानावर असलेल्या shared analytics आणि ads requests; SQL text त्यांपैकी कोणत्याचाही भाग नाही.

फॉर्मेटर हाताळल्यानंतर प्रिटी-प्रिंट केलेली SQL शैली-वाद राहत नाही. हे साधन पूर्णपणे तुमच्या ब्राउझरमध्ये चालते, क्वेरी पानातून बाहेर जात नाही आणि sql-formatter npm package मध्ये असलेला तोच dialect-aware tokenizer पुनर्लेखन करतो.