SQL फॉर्मैटर

डायलेक्ट चयनकर्ता क्यों मायने रखता है

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

अंतर विलक्षण नहीं हैं। अकेले पहचानकर्ता कोटिंग क्षेत्र को विभाजित करती है: MySQL बैकटिक का उपयोग करता है, PostgreSQL और मानक SQL डबल कोट का, और SQL Server वर्गाकार ब्रैकेट का। एक फॉर्मैटर जो गलत परंपरा मान ले, वह कोट किए गए पहचानकर्ता को स्ट्रिंग लिटरल मान सकता है और एक ऐसी सीमा के आसपास क्वेरी को फिर से बहा सकता है जो मौजूद ही नहीं है। कोटिंग के आगे LIMIT बनाम TOP बनाम FETCH FIRST, PostgreSQL का :: कास्ट ऑपरेटर, @ उपसर्ग वाले T-SQL वेरिएबल, BigQuery की बैकटिक-लिपटी प्रोजेक्ट पथ और Snowflake का QUALIFY खंड हैं। सही डायलेक्ट चुनना ही इन्हें बरकरार रखता है।

इंडेंटेशन एक डिफ़ निर्णय है

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

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

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

एक फॉर्मैटर क्या नहीं करेगा

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

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

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