SQL फॉर्मेटर/ब्यूटीफायर

SQL फॉर्मेटर/ब्यूटीफायर एक मुफ़्त टूल है, जो SQL कोड को अधिक पठनीय और एक समान ढंग से व्यवस्थित करके देता है।

SQL को फॉर्मेट करने पर क्या बदलता है?

SQL फॉर्मेटिंग किसी क्वेरी की प्रस्तुति बदलती है, ताकि उसके क्लॉज, एक्सप्रेशन और नेस्टेड संरचनाएं आसानी से समझी जा सकें। आम तौर पर SELECT सूचियों, JOIN क्लॉज, WHERE कंडीशन, सबक्वेरी और CASE एक्सप्रेशन जैसे हिस्सों में लाइन ब्रेक और इंडेंटेशन जोड़े जाते हैं।

फॉर्मेटिंग से क्वेरी का अपेक्षित परिणाम नहीं बदलना चाहिए। हालांकि, SQL डाइलेक्ट अलग-अलग होते हैं और केवल फॉर्मेटिंग से यह साबित नहीं होता कि स्टेटमेंट का अर्थ ज्यों का त्यों बना हुआ है। जनरेट किए गए SQL को प्रोडक्शन डेटा पर चलाने से पहले जांच लें, खासकर तब जब उसमें किसी वेंडर के विशेष ऑपरेटर, प्रोसीजरल एक्सटेंशन या असामान्य कोटिंग नियम इस्तेमाल हुए हों।

थर्ड-पार्टी क्वेरी पढ़ते समय, जनरेट किए गए SQL की समीक्षा करते समय, किसी लंबे स्टेटमेंट को डीबग करते समय या पुल रिक्वेस्ट के लिए कोड तैयार करते समय फॉर्मेटर उपयोगी होता है। एक समान लेआउट से बदलावों की तुलना करना भी आसान हो जाता है, क्योंकि स्पेसिंग के गैर-ज़रूरी अंतर कम हो जाते हैं।

SQL फॉर्मेटर का इस्तेमाल कैसे करें?

स्टेटमेंट को SQL फ़ील्ड में पेस्ट करें या लिखें, फिर उसे सबमिट करें। फॉर्मेट किया गया संस्करण फ़ॉर्मेट किया गया SQL में मिलेगा। प्रोसेसिंग के लिए इनपुट HTTPS के ज़रिए सर्वर पर भेजा जाता है और उसे स्टोर नहीं किया जाता।

1. पूरा स्टेटमेंट कॉपी करें। जिन common table expressions को बनाए रखना है, उन्हें भी शामिल करें। नतीजे में कमेंट और आखिर में लगे किसी भी सेमीकोलन की जांच करें।
2. जहां संभव हो, अलग-अलग टुकड़ों को फॉर्मेट करने के बजाय पूरा स्टेटमेंट SQL फ़ील्ड में डालें।
3. फ़ॉर्मेट किया गया SQL में नतीजा पढ़ें। नेस्टेड एक्सप्रेशन और डाइलेक्ट-विशिष्ट सिंटैक्स पर खास ध्यान दें।
4. फॉर्मेट किए गए स्टेटमेंट को डिप्लॉय करने से पहले किसी उपयुक्त डेवलपमेंट या स्टेजिंग एनवायरनमेंट में चलाएं।

संवेदनशील डेटाबेस से जुड़े काम में किसी भी सर्वर-आधारित यूटिलिटी को क्वेरी टेक्स्ट भेजने से पहले अपने संगठन की नीति जांच लें। क्वेरी समझने के लिए जिन पासवर्ड, एक्सेस टोकन, निजी डेटा और गोपनीय लिटरल वैल्यू की जरूरत नहीं है, उन्हें हटा दें।

फॉर्मेट किए गए SQL को कैसे पढ़ें?

नतीजे को इंडेंटेशन और क्लॉज की सीमाओं के अनुसार पढ़ें। नए लेआउट को इस बात का प्रमाण न मानें कि स्टेटमेंट मान्य है। हर तार्किक हिस्से को अपनी लाइन या इंडेंटेशन स्तर मिलने के बाद टॉप-लेवल SELECT, FROM, WHERE, GROUP BY और ORDER BY को अलग-अलग पहचानना आम तौर पर आसान हो जाता है।

• इंडेंट की गई सबक्वेरी दिखाती हैं कि अंदरूनी नतीजे का इस्तेमाल बाहरी स्टेटमेंट में कहां किया गया है।
• एक सीध में रखी गई कंडीशन से AND और OR की प्राथमिकता जांचना आसान होता है। हालांकि, डिफ़ॉल्ट रूप से AND को OR से अधिक प्राथमिकता मिलती है और तार्किक समूह अब भी कोष्ठकों से तय होते हैं।
• अलग-अलग JOIN क्लॉज यह पहचानने में मदद करते हैं कि कौन-सी ON कंडीशन किस टेबल से जुड़ी है।
• अलग-अलग पंक्तियों में फैली SELECT सूचियां छूटे हुए कॉमा, दोहराए गए कॉलम और अस्पष्ट एलियास पहचानना आसान बनाती हैं।
• साफ़ दिखाई देने वाली CASE शाखाएं समीक्षकों को WHEN, THEN, ELSE और END कीवर्ड का मिलान करने में मदद करती हैं।

कोट की गई स्ट्रिंग, संख्याएं, विराम-चिह्न और कमेंट SQL में अर्थ रखते हैं। इसलिए यह मानने के बजाय कि वे केवल प्रस्तुति का हिस्सा हैं, उनकी जांच करें। डेटाबेस और उसकी कैरेक्टर एन्कोडिंग के आधार पर, स्ट्रिंग लिटरल और कोट किए गए आइडेंटिफ़ायर में उच्चारण-चिह्न वाले या गैर-लैटिन वर्ण मान्य हो सकते हैं।

फॉर्मेटिंग के छोटे उदाहरण

इस संक्षिप्त इनपुट पर गौर करें।

इनपुट: SELECT id,name FROM customers WHERE active=1 ORDER BY name;

इसे पढ़ने में आसान रूप में इस तरह दिखाया जा सकता है।

आउटपुट: SELECT id, name

FROM customers

WHERE active = 1

ORDER BY name;

JOIN वाली क्वेरी में इंडेंटेशन और भी उपयोगी होता है।

इनपुट: SELECT o.id,c.name FROM orders o JOIN customers c ON c.id=o.customer_id WHERE o.total>100;

पठनीय आउटपुट में SELECT, FROM, JOIN, ON और WHERE को अलग-अलग पंक्तियों में रखा जा सकता है, जबकि तुलना o.total > 100 जस की तस रहती है। अलग-अलग फॉर्मेटिंग नियमों में बड़े-छोटे अक्षर, स्पेसिंग और लाइन की जगह बदल सकती है। इसलिए इन उदाहरणों को संभावित लेआउट मानें, किसी तय शैली की गारंटी नहीं।

क्या फॉर्मेटिंग SQL की गलतियां ढूंढ सकती है?

नहीं। SQL को सुंदर और व्यवस्थित बनाना, उसे डेटाबेस पार्सर से वैलिडेट करने जैसा नहीं है। इस टूल का घोषित नतीजा फॉर्मेट किया गया SQL है, इसलिए इसे सिंटैक्स चेकर, स्कीमा चेकर या एक्ज़ीक्यूशन प्लानर न मानें।

फिर भी, साफ़ लेआउट समीक्षा के दौरान संभावित गलतियां सामने ला सकता है। आम उदाहरणों में SELECT सूची में छूटा हुआ कॉमा, अधूरे कोष्ठक, बंद न की गई कोटेड स्ट्रिंग, अपेक्षित कंडीशन के बिना JOIN या गलत तरीके से समूहित AND या OR एक्सप्रेशन शामिल हैं। बिना कोट किए गए आइडेंटिफ़ायर के रूप में इस्तेमाल हुआ कोई रिज़र्व्ड शब्द भी अधिक आसानी से दिख सकता है।

कुछ समस्याओं का पता टारगेट डेटाबेस के बिना नहीं लगाया जा सकता। PostgreSQL में स्वीकार किया गया स्टेटमेंट Microsoft SQL Server, MySQL, Oracle Database या SQLite के लिए बदलना पड़ सकता है। गायब टेबल, अज्ञात कॉलम, असंगत डेटा टाइप और अनुमति संबंधी विफलताओं का पता लगाने के लिए आम तौर पर डेटाबेस इंजन या डाइलेक्ट की जानकारी रखने वाले डेवलपमेंट टूल की जरूरत होती है।

SQL को फॉर्मेट करना कब उपयोगी नहीं होता?

अगर SQL पहले से एक समान ढंग से फॉर्मेट किया गया है या उसे केवल मशीन इस्तेमाल करेगी, तो आम तौर पर दोबारा फॉर्मेट करने की जरूरत नहीं होती। जनरेट की गई क्वेरी को फिर से फॉर्मेट करने से सोर्स कंट्रोल में गैर-ज़रूरी बदलावों की भरमार हो सकती है, जबकि उसे बनाने वाले जनरेटर में कोई सुधार नहीं होता।

इन स्थितियों में भी फॉर्मेटिंग सही अगला कदम नहीं हो सकती:

• माइग्रेशन फ़ाइल को साइन किया गया हो, उसका चेकसम बनाया गया हो या उसकी किसी अन्य तरीके से बाइट-दर-बाइट तुलना होती हो।
• छोटी या संक्षिप्त की गई क्वेरी किसी ऐसे आर्टिफ़ैक्ट में एम्बेड हो जिसका आकार महत्वपूर्ण हो और किसी व्यक्ति को उसकी समीक्षा न करनी हो।
• तात्कालिक काम पठनीयता सुधारने के बजाय वैलिडेशन, एक्ज़ीक्यूशन प्लान का विश्लेषण या परफ़ॉर्मेंस ट्यूनिंग करना हो।
• क्वेरी में ऐसी गोपनीय वैल्यू हों जिन्हें संगठन की नीति सर्वर-आधारित सेवा को भेजने की अनुमति न देती हो।

पूरी रिपॉज़िटरी में एक समान और दोहराई जा सकने वाली फॉर्मेटिंग के लिए डाइलेक्ट की जानकारी रखने वाला कमांड-लाइन फॉर्मेटर अधिक उपयुक्त हो सकता है, क्योंकि उसकी कॉन्फ़िगरेशन को कोड के साथ कमिट किया जा सकता है। SQL वाले संरचित API पेलोड में आसपास के JSON की जांच के लिए JSON सत्यापनकर्ता और सौंदर्यीकरण उपकरण मदद कर सकता है, लेकिन SQL को फिर भी SQL-विशिष्ट तरीके से ही संभालना होगा।

अक्सर पूछे जाने वाले सवाल

क्या SQL फॉर्मेट करने से NULL का व्यवहार बदल जाएगा?

व्हाइटस्पेस और इंडेंटेशन से SQL का three-valued logic या NULL का व्यवहार नहीं बदलता। फिर भी, column = NULL जैसे एक्सप्रेशन जांचें, जिनमें आम तौर पर IS NULL की जरूरत होती है, क्योंकि फॉर्मेटर इस अर्थ संबंधी गलती को ठीक नहीं करेगा।

क्या कई SQL स्टेटमेंट एक साथ फॉर्मेट किए जा सकते हैं?

कई SQL स्टेटमेंट को एक साथ फॉर्मेट करने की सुविधा दर्ज नहीं है। हर स्टेटमेंट को अलग-अलग फॉर्मेट करें।

क्या इनपुट में कमेंट छोड़ना सुरक्षित है?

कमेंट में टिकट रेफ़रेंस, आंतरिक होस्टनेम, ग्राहक की जानकारी या संचालन संबंधी नोट हो सकते हैं, भले ही चलाए जाने वाले SQL में कोई संवेदनशील लिटरल न हो। टेक्स्ट को सर्वर पर भेजने से पहले लाइन कमेंट और ब्लॉक कमेंट, दोनों की समीक्षा करें।

SQL कीवर्ड बड़े अक्षरों में लिखें या छोटे अक्षरों में?

आम तौर पर दोनों शैलियां स्वीकार्य हैं, क्योंकि कई डेटाबेस इंजन बिना कोट किए गए कीवर्ड के बड़े-छोटे अक्षरों में अंतर नहीं करते। रिपॉज़िटरी में इस्तेमाल होने वाली शैली अपनाएं। कोट किए गए आइडेंटिफ़ायर के साथ सावधानी बरतें, क्योंकि कुछ डेटाबेस उनके अक्षरों का केस सुरक्षित रखते हैं या उसमें अंतर करते हैं।

फॉर्मेट की गई क्वेरी चलाने से पहले क्या जांचें?

टारगेट डेटाबेस डाइलेक्ट की पुष्टि करें, WHERE और JOIN कंडीशन जांचें और UPDATE, DELETE तथा स्कीमा बदलने वाले स्टेटमेंट के लिए ट्रांज़ैक्शन की सीमाएं सत्यापित करें। जोखिम वाली क्वेरी पहले डेवलपमेंट या स्टेजिंग डेटाबेस में चलाएं। बेहतर होगा कि वहां वास्तविक परिस्थितियों से मेल खाता डेटा और उपयुक्त बैकअप मौजूद हों।