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

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

SQL फ़ॉर्मेटिंग एक lexer-driven rewrite है जो क्वेरी के हर token को traverse करता है और चुने हुए dialect के नियमों के अनुसार उसके आसपास whitespace पुनः उत्सर्जित करता है। क्वेरी का अर्थ नहीं बदलता — केवल layout बदलता है।

1. डायलेक्ट चुनें. MySQL backticks, PostgreSQL :: casts, BigQuery dotted table paths, और T-SQL square-bracket identifiers — हर एक को उन्हें पहचानने वाले tokenizer की ज़रूरत है। Dialect selector तय करता है कि कौन सा grammar लागू हो।
2. Input को Tokenize करें. फ़ॉर्मेटर क्वेरी को tokens की stream में विभाजित करता है: keywords (SELECT, JOIN), identifiers, literals, operators, parentheses और comments। String literals और quoted identifiers अपरिवर्तित पास होते हैं।
3. Layout Rules लागू करें. Top-level clauses (SELECT, FROM, WHERE, GROUP BY, ORDER BY) अपनी-अपनी लाइन पर आते हैं। Select list और column lists में comma-separated expressions प्रत्येक एक लाइन पर, चुने हुए indent unit से indented।
4. Keyword Case लागू करें. Keyword-case toggle पहचाने गए SQL keywords को uppercase, lowercase में rewrite करता है या input casing verbatim preserve करता है। Identifiers कभी नहीं बदलते — column और table names हमेशा जैसे लिखे हैं वैसे ही आते हैं।
5. Formatted String Output करें. Token stream को indent character (2 spaces, 4 spaces, या tab) और configured linebreak rule के साथ एक string में join किया जाता है। Live mode टाइप करते समय 200 ms debounce पर पूरा pipeline पुनः चलाता है।

SQL को प्रिटी-प्रिंट क्यों करें

• Pull-request diff की पठनीयता. 200-लाइन CTE को एक लाइन में rewrite करने से code review अनुमान लगाने का खेल बन जाता है। Consistent formatting diff को असली बदलाव तक सीमित रखता है — नया column, extra JOIN, अलग WHERE predicate — reviewer whitespace सुलझाए बिना देख सकता है।
• Debugging आसान. जब क्वेरी गलत row count देती है तो पहला काम उसे लाइन-दर-लाइन पढ़ना होता है। Formatted SQL हर JOIN को अपनी लाइन पर रखता है और WHERE predicates को align करता है, जिससे छूटा हुआ AND या अनचाहा OR एक नज़र में दिखता है।
• Team style एकसमान. अधिकतर टीमें SQL style guide अपनाती हैं (dbt Labs, GitLab, Mode Analytics सभी प्रकाशित करते हैं) और हर committed क्वेरी उसका पालन चाहती हैं। Commit से पहले formatter चलाने से review में style argument हट जाता है और केवल logic पर चर्चा रहती है।
• Docs में SQL share करना. Runbooks, incident retros और Notion docs सभी ऊपर-से-नीचे पढ़ने योग्य SQL से लाभ उठाते हैं। Formatted SQL fenced code block में साफ paste होता है और PDF export में predictably print होता है।

सामान्य उपयोग के मामले

SQL formatting analytics engineering, backend development और operations में हर जगह दिखती है जब कोई ऐसा क्वेरी पढ़ता है जो उसने नहीं लिखा।

• Analytics engineering: dbt project में pre-commit hook जो हर model file को reformat करे ताकि PR diffs logic changes तक सीमित रहें, whitespace churn नहीं।
• Database administration: slow-query log की एक-लाइन entry paste करें, format करें, और incident retro लिखते हुए join order walk करें।
• Documentation: Looker explore या Tableau workbook से क्वेरी निकालें, runbook के लिए format करें, और on-call rotation के लिए copy-pasteable example embed करें।

एक उदाहरण

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; को input pane में paste करें, dialect PostgreSQL, indent 2 spaces, keyword case UPPER सेट करें। Output में SELECT, FROM, LEFT JOIN, WHERE, GROUP BY और ORDER BY अपनी-अपनी लाइन पर होंगे; select list और group-by list का हर column अपनी indented लाइन पर; ON predicate JOIN keyword से एक indent गहरा।

FAQ

कौन से SQL dialects support हैं?

Dialect dropdown में Standard SQL, MySQL, PostgreSQL, SQLite, MariaDB, Transact-SQL (SQL Server / Azure SQL), BigQuery, Snowflake और Redshift शामिल हैं। Underlying sql-formatter library DuckDB, Spark SQL, Hive, Trino, Db2, N1QL, PL/SQL, ClickHouse, TiDB और SingleStoreDB भी पहचानती है। Identifiers, string literals और dialect-specific operators (PostgreSQL @>, BigQuery SAFE. prefixes) verbatim preserve होते हैं।

क्या यह मेरी SQL validate करता है?

नहीं। Formatter एक lexical rewriter है, parser नहीं। यह input tokenize करता है, layout rules लागू करता है और result emit करता है; यह नहीं जाँचता कि क्वेरी semantically valid है, referenced tables exist करती हैं, या syntax chosen dialect में legal है। Real correctness check के लिए formatted output को actual database (या SQLFluff जैसे SQL linter) से गुज़ारें।

मेरे keywords uppercase क्यों हो रहे हैं?

Keyword case dropdown default UPPER है, जो अधिकतर published SQL style guides (dbt Labs, Mode, GitLab) का convention है। यदि आपकी team select / from lowercase लिखती है तो lower चुनें, या यदि आप अपनी casing preserve चाहते हैं तो Preserve चुनें। Identifiers कभी प्रभावित नहीं होते।

क्या मेरी क्वेरी कहीं upload होती है?

नहीं। Vendored sql-formatter library आपके browser में चलती है, formatting आपके machine पर locally होती है, और query text network से नहीं गुज़रता। इस page के एकमात्र outbound requests वही shared analytics और ads requests हैं जो tools.ultim8soft.com के हर page पर होते हैं; SQL text उनमें से किसी का हिस्सा नहीं।

Formatted SQL एक बार formatter से गुज़रने के बाद style argument नहीं रहता। यह टूल पूरी तरह आपके browser में चलता है, क्वेरी page नहीं छोड़ती, और वही dialect-aware tokenizer rewrite करता है जो sql-formatter npm package में है।