SQL queries format _

SQL formatting how works

SQL ફોર્મેટિંગ એ lexer-આધારિત પુનઃલેખન છે જે ક્વેરીના દરેક token પર ફરી વળે છે અને પસંદ કરેલા dialect ના નિયમો અનુસાર તેની આસપાસ ખાલી જગ્યા ફરી ઉત્સર્જિત કરે છે. ક્વેરીનો અર્થ ક્યારેય બદલાતો નથી, માત્ર લેઆઉટ બદલાય છે.

1. Dialect pick. MySQL backticks, PostgreSQL :: casts, BigQuery dotted table paths, અને T-SQL square-bracket identifiers — દરેકને એવા tokenizer ની જરૂર છે જે તેમના વિશે જાણતો હોય. Dialect selector નક્કી કરે છે કે કયું grammar લાગુ કરવું.
2. Input tokenize. ફોર્મેટર ક્વેરીને tokens ની એક સ્ટ્રીમમાં વિભાજિત કરે છે: keywords (SELECT, JOIN), identifiers, literals, operators, parentheses, અને comments. String literals અને quoted identifiers અસ્પૃશ્ય રીતે પસાર થાય છે જેથી dialect-વિશિષ્ટ syntax કામ કરતું રહે.
3. Layout rules apply. Top-level clauses (SELECT, FROM, WHERE, GROUP BY, ORDER BY) પોતપોતાની પંક્તિ પર શરૂ થાય છે. Select list અને column lists માં comma-વિભાજિત expressions દરેકને એક પંક્તિ મળે છે, જે પસંદ કરેલા indent એકમ વડે indented હોય છે.
4. Keyword case apply. Keyword-case toggle ઓળખાયેલા SQL keywords ને uppercase, lowercase માં ફરી લખે છે, અથવા ઇનપુટની casing જેમ છે તેમ જાળવી રાખે છે. Identifiers ને ક્યારેય સ્પર્શ થતો નથી — column અને table નામો હંમેશા જેમ લખ્યા હોય તેમ જ આવે છે.
5. ફોર્મેટ કરેલી સ્ટ્રિંગ બહાર કાઢો. Token stream ને indent અક્ષર (2 spaces, 4 spaces, અથવા tab) અને રૂપરેખાંકિત linebreak નિયમ સાથે પાછી એક જ સ્ટ્રિંગમાં જોડવામાં આવે છે. તમે ટાઇપ કરો ત્યારે Live mode 200 ms ના debounce પર આખી પાઇપલાઇન ફરી ચલાવે છે.

SQL pretty-print why?

• Pull-request diff વાંચવામાં સરળ. 200-પંક્તિના CTE ને એક પંક્તિ તરીકે ફરી લખવાથી code review અનુમાન લગાવવાની રમત બની જાય છે. સુસંગત ફોર્મેટિંગ diff ને તમે ખરેખર કરેલા ફેરફાર પૂરતું જ સીમિત રાખે છે — એક નવો column, એક વધારાનો JOIN, એક અલગ WHERE predicate — જેથી reviewer ખાલી જગ્યા ઉકેલ્યા વગર તે જોઈ શકે.
• Debug easier. જ્યારે ક્વેરી ખોટી row count પાછી આપે છે, ત્યારે પહેલું કામ તેને પંક્તિ-દર-પંક્તિ વાંચવાનું હોય છે. Formatted SQL દરેક JOIN ને પોતાની પંક્તિ પર મૂકે છે અને WHERE predicates ને ગોઠવી દે છે જેથી છૂટી ગયેલો AND અથવા ભટકતો OR એક નજરમાં દેખાઈ આવે.
• ટીમ style સુસ્થિર. મોટાભાગની ટીમો SQL style guide અપનાવે છે (dbt Labs, GitLab, Mode Analytics બધા પોતપોતાનું પ્રકાશિત કરે છે) અને ઇચ્છે છે કે દરેક committed ક્વેરી તેનું પાલન કરે. Commit પહેલાં formatter ચલાવવાથી review માંથી style ની દલીલ નીકળી જાય છે અને ચર્ચા માટે માત્ર logic બાકી રહે છે.
• SQL docs share. Runbooks, incident retros, અને Notion docs બધાને એવા SQL થી લાભ થાય છે જે ઉપરથી નીચે વાંચી શકાય. Formatted SQL એક fenced code block માં ચોખ્ખું paste થાય છે અને PDF exports માં અપેક્ષિત રીતે છપાય છે, keyword ની વચ્ચે કોઈ વિચિત્ર line wraps વગર.

સામાન્ય ઉપયોગો

SQL ફોર્મેટિંગ analytics engineering, backend development, અને operations કાર્યમાં દરેક જગ્યાએ દેખાય છે — જ્યારે પણ કોઈ ક્વેરી એવી વ્યક્તિએ વાંચવી પડે જેણે તે લખી નથી.

• Analytics engineering: dbt project માં pre-commit hook જે દરેક model ફાઇલને ફરી ફોર્મેટ કરે જેથી PR diffs logic ફેરફારો પૂરતા સીમિત રહે, ખાલી જગ્યાના મંથન પૂરતા નહીં.
• Database administration: slow-query log ની એક-પંક્તિ entry paste કરો, તેને ફોર્મેટ કરો, અને incident retro લખતી વખતે join ક્રમમાંથી પસાર થાઓ.
• Documentation: Looker explore અથવા Tableau workbook માંથી એક ક્વેરી કાઢો, runbook માટે તેને ફોર્મેટ કરો, અને on-call rotation માટે copy-paste કરી શકાય તેવા ઉદાહરણ તરીકે તેને embed કરો.

Worked example

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 માં paste કરો, 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 ઊંડે બેસે છે. એ જ ક્વેરી BigQuery dialect વડે આ કિસ્સામાં સમાન આઉટપુટ આપે છે પણ જો કોઈ backtick-quoted identifiers હાજર હોત તો તેમને જાળવી રાખત.

FAQ

કયા SQL ડાયલેક્ટ આધારભૂત છે?

Dialect dropdown માં Standard SQL, MySQL, PostgreSQL, SQLite, MariaDB, Transact-SQL (SQL Server / Azure SQL), BigQuery, Snowflake, અને Redshift આવરી લેવાય છે. અંતર્ગત sql-formatter લાઇબ્રેરી DuckDB, Spark SQL, Hive, Trino, Db2, N1QL, PL/SQL, ClickHouse, TiDB, અને SingleStoreDB ને પણ ઓળખે છે — સૌથી નજીકનું dialect પસંદ કરવાથી, જ્યારે ચોક્કસ લક્ષ્ય યાદીમાં ન હોય ત્યારે પણ સમજદાર આઉટપુટ મળે છે. Identifiers, string literals, અને dialect-વિશિષ્ટ operators (PostgreSQL @>, BigQuery SAFE. prefixes) જેમના તેમ જાળવી રાખવામાં આવે છે.

શું આ મારી SQL ને માન્ય કરે છે?

ના. ફોર્મેટર એક lexical પુનઃલેખક છે, parser નહીં. તે ઇનપુટને tokenize કરે છે, layout નિયમો લાગુ કરે છે, અને પરિણામ ઉત્સર્જિત કરે છે; તે તપાસતું નથી કે ક્વેરી semantically valid છે કે કેમ, સંદર્ભિત tables અસ્તિત્વમાં છે કે કેમ, અથવા syntax પસંદ કરેલા dialect માં માન્ય છે કે કેમ. ખરી શુદ્ધતા તપાસવા માટે formatted આઉટપુટને વાસ્તવિક database (અથવા SQLFluff જેવા SQL linter) માંથી પસાર કરો.

મારા કીવર્ડ શા માટે મોટા અક્ષરમાં થઈ રહ્યા છે?

Keyword case dropdown મૂળભૂત રીતે UPPER હોય છે, જે મોટાભાગના પ્રકાશિત SQL style guides (dbt Labs, Mode, GitLab) નો સંપ્રદાય છે. જો તમારી ટીમ select / from lowercase માં લખે છે તો lower પસંદ કરો, અથવા જો તમે ઇચ્છો કે આઉટપુટ તમે ટાઇપ કરી હોય તે casing જાળવી રાખે તો Preserve પસંદ કરો. Identifiers ને ક્યારેય અસર થતી નથી — માત્ર ઓળખાયેલા keyword સમૂહને ફરી લખવામાં આવે છે.

શું મારી ક્વેરી ક્યાંય અપલોડ થાય છે?

ના. Vendored sql-formatter લાઇબ્રેરી તમારા બ્રાઉઝરમાં ચાલે છે, ફોર્મેટિંગ તમારા મશીન પર સ્થાનિક રીતે થાય છે, અને ક્વેરી લખાણ ક્યારેય નેટવર્ક ઓળંગતું નથી. આ page જે એકમાત્ર બહારી requests કરે છે તે એ જ વહેંચાયેલા analytics અને ads requests છે જે tools.ultim8soft.com ના દરેક page કરે છે; SQL લખાણ પોતે તેમાંના કોઈનો ભાગ નથી.

Pretty-printed SQL formatter handle — style argument. Browser, query page never leave, sql-formatter npm package power same dialect-aware tokenizer rewrite.