SQL فارمیٹنگ کیسے کام کرتی ہے
SQL فارمیٹنگ lexer سے چلنے والی دوبارہ تحریر ہے جو استعلام کے ہر ٹوکن پر چلتی ہے اور منتخب لہجے کے اصولوں کی بنیاد پر اس کے گرد خالی جگہ دوبارہ خارج کرتی ہے۔ استعلام کی معنویت کبھی نہیں بدلتی، صرف ترتیب بدلتی ہے۔
- لہجہ چنیں. MySQL کے backticks، PostgreSQL کے
::casts، BigQuery کے dotted table paths، اور T-SQL کے square-bracket identifiers — ہر ایک کو ایسے tokenizer کی ضرورت ہے جو انہیں جانتا ہو۔ لہجہ منتخب کرنے سے طے ہوتا ہے کہ کونسی grammar لاگو کی جائے۔ - ان پٹ کو tokenize کریں. فارمیٹر استعلام کو ٹوکنز کے سلسلے میں تقسیم کرتا ہے: keywords (
SELECT،JOIN)، identifiers، literals، operators، parentheses اور comments۔ string literals اور quoted identifiers بغیر تبدیلی کے گزارے جاتے ہیں تاکہ لہجہ مخصوص syntax کام کرتی رہے۔ - ترتیب کے اصول لاگو کریں. اعلیٰ سطحی شقیں (
SELECT،FROM،WHERE،GROUP BY،ORDER BY) اپنی الگ سطر پر شروع ہوتی ہیں۔ select list اور column lists میں comma سے علیحدہ ہر اظہار منتخب indent unit کے ساتھ اپنی سطر پاتا ہے۔ - keyword case لاگو کریں. keyword-case toggle پہچانے گئے SQL keywords کو uppercase، lowercase میں دوبارہ لکھتا ہے یا ان پٹ casing کو بالکل محفوظ رکھتا ہے۔ Identifiers کبھی نہیں چھوئے جاتے — column اور table کے نام ہمیشہ جیسے لکھے ویسے ہی آتے ہیں۔
- فارمیٹ شدہ سٹرنگ خارج کریں. ٹوکن سلسلے کو indent character (2 اسپیس، 4 اسپیس یا ٹیب) اور configured linebreak rule کے ساتھ واپس ایک سٹرنگ میں جوڑا جاتا ہے۔ لائیو موڈ ٹائپ کرتے وقت 200 ms debounce پر پوری pipeline دوبارہ چلاتا ہے۔
SQL کو خوش نما انداز میں کیوں پرنٹ کریں
- pull-request diff کی قابلیتِ مطالعہ. 200 سطری CTE کو ایک سطر میں لکھنا code review کو اندازے کا کھیل بنا دیتا ہے۔ یکساں فارمیٹنگ diff کو اصل تبدیلی تک محدود رکھتی ہے — نیا column، اضافی
JOIN، مختلفWHEREشرط — تاکہ reviewer خالی جگہوں کی الجھن سلجھائے بغیر دیکھ سکے۔ - آسان debugging. جب کوئی استعلام غلط row count لوٹائے تو پہلا کام اسے سطر بہ سطر پڑھنا ہے۔ فارمیٹ شدہ SQL ہر
JOINکو اپنی سطر پر رکھتا ہے اورWHEREشرطوں کو صف میں لاتا ہے تاکہ غائبANDیا بھٹکا ہواORایک نظر میں نظر آئے۔ - ٹیم کا یکساں اسلوب. زیادہ تر ٹیمیں SQL style guide اپناتی ہیں (dbt Labs، GitLab، Mode Analytics سب اپنی گائیڈ شائع کرتے ہیں) اور چاہتی ہیں کہ commit ہونے والا ہر استعلام اس کی پیروی کرے۔ commit سے پہلے چلایا گیا فارمیٹر review سے اسلوب کی بحث ہٹا دیتا ہے اور صرف منطق زیرِ بحث رہتی ہے۔
- دستاویزات میں SQL شیئر کرنا. Runbooks، incident retros اور Notion docs سب اس SQL سے فائدہ اٹھاتے ہیں جو اوپر سے نیچے پڑھی جاتی ہے۔ فارمیٹ شدہ SQL fenced code block میں صاف چسپاں ہوتی ہے اور PDF exports میں قابلِ انداز طریقے سے پرنٹ ہوتی ہے، کسی keyword کے درمیان کوئی عجیب لائن wrap نہیں۔
عام استعمالات
SQL فارمیٹنگ analytics engineering، backend development اور operations میں جب بھی کسی ایسے شخص کو استعلام پڑھنی ہو جس نے اسے نہیں لکھا تو نظر آتی ہے۔
- Analytics engineering: dbt project میں pre-commit hook جو ہر model file کو دوبارہ فارمیٹ کرتا ہے تاکہ PR diffs منطقی تبدیلیوں تک محدود رہیں، خالی جگہوں کے اتھل پتھل تک نہیں۔
- Database administration: ایک سطری slow-query log entry چسپاں کریں، اسے فارمیٹ کریں، اور 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; ان پٹ پین میں چسپاں کریں جبکہ 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 شرط اپنے JOIN keyword سے ایک indent گہری ہوتی ہے۔
FAQ
کون سے SQL لہجے سپورٹ ہیں؟
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 کو بھی پہچانتی ہے — قریب ترین لہجہ چننا قابلِ قبول آؤٹ پٹ دیتا ہے چاہے عین ہدف فہرست میں نہ ہو۔ Identifiers، string literals اور لہجہ مخصوص operators (PostgreSQL @>، BigQuery SAFE. prefixes) بالکل محفوظ رہتے ہیں۔
کیا یہ میرے SQL کی تصدیق کرتا ہے؟
نہیں۔ فارمیٹر lexical rewriter ہے، parser نہیں۔ یہ ان پٹ کو tokenize کرتا ہے، layout rules لاگو کرتا ہے اور نتیجہ خارج کرتا ہے؛ یہ نہیں جانچتا کہ استعلام معنوی طور پر درست ہے یا حوالہ دی گئی tables موجود ہیں یا چنے گئے لہجے میں syntax قانونی ہے۔ حقیقی درستگی کے لیے فارمیٹ شدہ آؤٹ پٹ کو اصل database (یا SQLFluff جیسے SQL linter) سے گزاریں۔
میرے keywords uppercase کیوں ہو رہے ہیں؟
Keyword case dropdown کی ڈیفالٹ سیٹنگ UPPER ہے جو زیادہ تر شائع شدہ SQL style guides (dbt Labs، Mode، GitLab) کا اصول ہے۔ اگر آپ کی ٹیم select / from چھوٹے حروف میں لکھتی ہے تو lower چنیں، یا Preserve اگر آؤٹ پٹ وہی casing رکھنا چاہتے ہیں جو آپ نے ٹائپ کی۔ Identifiers کبھی متاثر نہیں ہوتے — صرف پہچانے گئے keyword سیٹ کو دوبارہ لکھا جاتا ہے۔
کیا میرا استعلام کہیں اپلوڈ ہوتا ہے؟
نہیں۔ vendored sql-formatter library آپ کے براؤزر میں چلتی ہے، فارمیٹنگ آپ کی مشین پر مقامی طور پر ہوتی ہے، اور استعلام کا متن کبھی نیٹ ورک نہیں پار کرتا۔ یہ صفحہ جو واحد باہری درخواستیں کرتا ہے وہ وہی مشترکہ analytics اور ads درخواستیں ہیں جو tools.ultim8soft.com پر ہر صفحہ کرتا ہے؛ SQL متن کسی میں بھی شامل نہیں۔
SQL کو خوش نما انداز میں پرنٹ کرنا اسلوب کی بحث نہیں رہتا جب فارمیٹر یہ کام سنبھال لے۔ ٹول مکمل طور پر آپ کے براؤزر میں چلتا ہے، استعلام کبھی صفحے سے باہر نہیں جاتا، اور وہی لہجہ واقف lexer جو sql-formatter npm package کو چلاتا ہے دوبارہ تحریر کا کام کرتا ہے۔