SQL फ़ॉर्मेटर

कोई फ़ॉर्मेटर जो पूरे शब्दों की किसी रेगुलर एक्सप्रेशन से तुलना करके कीवर्ड अपरकेस करता है, उसके पास यह जानने का कोई तरीक़ा नहीं कि "order" का कोई दिया गया मौजूदगी SQL कीवर्ड `ORDER` (जैसे `ORDER BY` में) है या कोई लिटरल स्ट्रिंग वैल्यू जिसमें इत्तेफ़ाक़न वह शब्द है — `WHERE description = 'the order from stock'` फ़िल्टर करने वाली क्वेरी में "order" शब्द किसी कोट की गई स्ट्रिंग के अंदर है, बिल्कुल भी कीवर्ड की तरह काम नहीं कर रहा। कोई भोला फ़ॉर्मेटर संदर्भ की परवाह किए बिना हर मैच होते शब्द को अपरकेस कर देता है, `'the ORDER FROM stock'` में लिटरल स्ट्रिंग वैल्यू बिगाड़ते हुए और चुपचाप बदलते हुए कि क्वेरी असल में क्या फ़िल्टर करती है। क्वेरी को सही तरीक़े से टोकनाइज़ करना — यह तय करने से पहले कोट की गई स्ट्रिंग की सीमाएँ पहचानना कि क्या कीवर्ड गिना जाए — यही इसे रोकता है, और यह ठीक उसी तरह की ग़लती है जो सिर्फ़ ऐसे असली डेटा के साथ दिखती है जिसमें इत्तेफ़ाक़न SQL कीवर्ड से मेल खाते शब्द हों, यही वजह है कि सरल उदाहरण क्वेरी से टेस्ट करते समय इसे नज़रअंदाज़ करना आसान है।

यह टूल PostgreSQL, MySQL, SQL Server, SQLite और Oracle के बीच साझा आम क्लॉज़ संरचना को — SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY और उनके रिश्तेदारों को — इतना अच्छे से पहचानता है कि हर क्लॉज़ को अपनी लाइन पर इंडेंट कर सके और सबक्वेरी को सही तरीक़े से नेस्ट कर सके। यह किसी ख़ास डेटाबेस की पूरी व्याकरण की पूरी समझ नहीं बनाता, जिसमें PostgreSQL की array सिंटैक्स या SQL Server की `TOP` क्लॉज़ की जगह जैसे वेंडर-ख़ास एक्सटेंशन शामिल हैं। व्यावहारिक नतीजा यह है कि किसी बोली की ख़ास सिंटैक्स एरर पैदा करने की बजाय फ़ॉर्मेटर से बिना छुए गुज़र जाती है, लेकिन उसे भी वही सावधानी वाली इंडेंटेशन नहीं मिलेगी जो आम क्लॉज़ को मिलती है — हर डेटाबेस इंजन के लिए अलग टूल चाहने की बजाय एक ही फ़ॉर्मेटर से पाँच बोलियाँ सपोर्ट करने के लिए यह एक उचित समझौता है।

SQL कीवर्ड ख़ुद भाषा की स्पेसिफ़िकेशन के हिसाब से केस-सेंसिटिव नहीं हैं — `SELECT`, `Select` और `select` किसी भी SQL इंजन के लिए एक जैसे हैं — जो ठीक वही चीज़ है जो उन्हें अपरकेस या lowercase करने को व्यवहार बदलने के किसी भी जोखिम के बिना पूरी तरह कॉस्मेटिक ऑपरेशन बनाती है। यही बात इस फ़ॉर्मेटर द्वारा जोड़े गए व्हाइटस्पेस और लाइन ब्रेक के साथ भी है: बारह इंडेंट की लाइनों में फैली कोई क्वेरी एक ही लाइन में ठूँसी गई उसी क्वेरी की तरह बिल्कुल एक जैसा चलती है। फ़ॉर्मेटिंग का कोई भी हिस्सा उन असली टोकन को नहीं छूता जो तय करते हैं कौन सी टेबल पढ़ी जाती हैं, कौन सी शर्तें पंक्तियाँ फ़िल्टर करती हैं, या कौन सी वैल्यू डाली जाती हैं — सिर्फ़ यह कि बाद में उसे पढ़ने वाले इंसान के लिए वही तार्किक क्वेरी विज़ुअली कैसे व्यवस्थित की जाती है।

किसी ORM द्वारा जेनरेट की गई, किसी डेटाबेस GUI से एक्सपोर्ट की गई, या किसी जल्दबाज़ी वाली माइग्रेशन के दौरान एक लंबी लाइन के रूप में लिखी गई क्वेरी आमतौर पर फ़ंक्शनली सही होती है लेकिन जैसी लिखी गई वैसे किसी इंसान के लिए रिव्यू करना वाक़ई मुश्किल है — बिना लाइन ब्रेक के पंद्रह जॉइन वाली कोई क्वेरी यह देखना मुश्किल बना देती है कि कौन सी शर्तें किस जॉइन की हैं, या कोई WHERE क्लॉज़ सही टेबल फ़िल्टर कर रही है या नहीं। इसे हर क्लॉज़ और हर जॉइन को अपनी लाइन पर रखते हुए, क्वेरी की असली संरचना दर्शाने के लिए इंडेंट करते हुए, दोबारा फ़ॉर्मेट करना आमतौर पर कोड रिव्यू में इसे मंज़ूर करने या यह डीबग करने से पहले कि यह ग़लत पंक्तियाँ क्यों लौटा रही है, किसी लंबी जेनरेट की क्वेरी को असल में समझने का सबसे तेज़ तरीक़ा है।