SQL गाइड: प्रश्न कैसे लिखें बेहतर (भाग 1)

एंटीपैटर्न, निष्पादन योजना, समय जटिलता, क्वेरी ट्यूनिंग और SQL अनुकूलन के बारे में जानें

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

यही कारण है कि यह एसक्यूएल गाइड आपको कुछ ऐसे चरणों के बारे में बताएगा जो आप अपनी क्वेरी का मूल्यांकन करने के लिए कर सकते हैं:

• सबसे पहले, आप डेटा विज्ञान के क्षेत्र में काम करने के लिए SQL सीखने के महत्व का एक संक्षिप्त अवलोकन के साथ शुरू करेंगे;
• अगला, आप पहले सीखेंगे कि गुणवत्ता प्रश्नों को बनाने के महत्व को समझने के लिए SQL प्रश्नों को कैसे संसाधित और निष्पादित किया जाए। अधिक विशेष रूप से, आप देखेंगे कि अनुरोध का विश्लेषण, पुन: लिखित, अनुकूलित और अंत में मूल्यांकन किया गया है।
• इसे ध्यान में रखते हुए, आप न केवल प्रश्नों के कुछ एंटीपैटर्न पर जाएंगे, जो प्रश्न लिखते समय शुरुआती करते हैं, बल्कि इन संभावित गलतियों के विकल्प और समाधान के बारे में भी अधिक सीखते हैं; इसके अलावा, आप सेट-आधारित क्वेरी दृष्टिकोण के बारे में अधिक जानेंगे।
• आप यह भी देखेंगे कि ये एंटीपार्टर्न प्रदर्शन की समस्याओं से उपजी हैं और SQL प्रश्नों को सुधारने के लिए "मैनुअल" दृष्टिकोण के अलावा, आप कुछ अन्य उपकरणों का उपयोग करके अपने प्रश्नों का विश्लेषण अधिक संरचित, गहराई से कर सकते हैं, जो आपको क्वेरी प्लान देखने में मदद करते हैं; और,
• आप अनुरोध को निष्पादित करने से पहले समय में निष्पादन योजना की जटिलता का अंदाजा लगाने के लिए समय जटिलता और बड़े ओ संकेतन के बारे में जानेंगे;
• आप अपनी क्वेरी का अनुकूलन करना सीखेंगे।

आपको डेटा के साथ काम करने के लिए SQL क्यों सीखना चाहिए?

एसक्यूएल मृत से दूर है: यह सबसे अधिक मांग वाले कौशल में से एक है जो आपको डेटा प्रोसेसिंग और विश्लेषण उद्योग से नौकरी विवरण में मिलता है, चाहे आप डेटा एनालिटिक्स, डेटा इंजीनियर, डेटा विशेषज्ञ या किसी अन्य भूमिकाओं के लिए आवेदन करें। 2016 के लिए O 'Reilly Data Science Salary Survey के 70% उत्तरदाताओं द्वारा इसकी पुष्टि की गई है, जो संकेत देते हैं कि वे अपने व्यावसायिक संदर्भ में SQL का उपयोग करते हैं। इसके अलावा, इस सर्वेक्षण में, SQL प्रोग्रामिंग भाषाओं R (57%) और पायथन (54%) से ऊपर है।

आपको चित्र मिलता है: जब आप आईटी उद्योग में नौकरी कर रहे होते हैं तो एसक्यूएल एक आवश्यक कौशल होता है।

1970 के दशक की शुरुआत में विकसित हुई भाषा के लिए बुरा नहीं, है ना?

लेकिन ऐसा अक्सर क्यों किया जाता है? और वह इतने लंबे समय तक अस्तित्व में होने के बावजूद मर क्यों नहीं गया?

कई कारण हैं: पहला कारण यह हो सकता है कि कंपनियां मुख्य रूप से रिलेशनल डेटाबेस मैनेजमेंट सिस्टम (RDBMS) या रिलेशनल डेटा फ़्लो मैनेजमेंट सिस्टम (RDSMS) में डेटा स्टोर करती हैं, और SQL को इस डेटा तक पहुंचने की आवश्यकता होती है। एसक्यूएल डेटा का लिंगुआ फ्रेंका है : यह लगभग किसी भी डेटाबेस के साथ बातचीत करना या स्थानीय स्तर पर अपना स्वयं का निर्माण करना संभव बनाता है!

यदि यह अभी भी पर्याप्त नहीं है, तो ध्यान रखें कि काफी कुछ एसक्यूएल कार्यान्वयन हैं जो विक्रेताओं के बीच असंगत हैं और जरूरी नहीं कि मानकों के अनुरूप हों। इसलिए, मानक एसक्यूएल का ज्ञान आपको उद्योग (कंप्यूटर विज्ञान) में अपना रास्ता खोजने के लिए एक आवश्यकता है।

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

यदि आप एक तुलना करना चाहते हैं, तो इसे रैखिक बीजगणित सीखने के रूप में मानें: इन सभी प्रयासों को इस एक विषय में डालते हुए, आप जानते हैं कि आप इसे मास्टर मशीन सीखने के लिए भी उपयोग कर सकते हैं!

संक्षेप में, यही कारण है कि आपको यह क्वेरी भाषा सीखनी चाहिए:

• यह सीखने में काफी आसान है, यहां तक ​​कि शुरुआती के लिए भी। सीखने की अवस्था काफी सरल और क्रमिक है, इसलिए आप जितनी जल्दी हो सके प्रश्नों को लिखेंगे।
• यह "एक बार सीखो, हर जगह उपयोग करो" के सिद्धांत का अनुसरण करता है, इसलिए यह आपके समय का एक महान निवेश है!
• यह प्रोग्रामिंग भाषाओं के लिए एक बढ़िया अतिरिक्त है; कुछ मामलों में, क्वेरी लिखना कोड लिखने के लिए भी बेहतर है, क्योंकि यह अधिक कुशल है!
• ...

क्या आप अभी भी इंतजार कर रहे हैं? :)

SQL प्रसंस्करण और क्वेरी निष्पादन

अपनी SQL क्वेरी के प्रदर्शन को बेहतर बनाने के लिए, आपको पहले यह जानना होगा कि क्वेरी को निष्पादित करने के लिए शॉर्टकट पर क्लिक करने पर आपके अंदर क्या होता है।

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

फिर, ऑप्टिमाइज़र को दिए गए क्वेरी के लिए इष्टतम निष्पादन या क्वेरी योजना ढूंढनी होगी। निष्पादन योजना सटीक रूप से निर्धारित करती है कि प्रत्येक ऑपरेशन के लिए कौन सा एल्गोरिदम उपयोग किया जाता है, और ऑपरेशन कैसे समन्वित होते हैं।

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

अब आप शायद सोच रहे हैं कि "अच्छी क्वेरी योजना" क्या है।

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

फिर, चयनित क्वेरी योजना को निष्पादित किया जाता है, सिस्टम निष्पादन तंत्र द्वारा मूल्यांकन किया जाता है, और क्वेरी परिणाम वापस किए जाते हैं।

SQL क्वेरी लिखना

यह पिछले खंड से स्पष्ट नहीं हो सकता है कि गारबेज इन, गारबेज आउट (जीआईजीओ) का सिद्धांत स्वाभाविक रूप से एक क्वेरी को संसाधित करने और निष्पादित करने की प्रक्रिया में खुद को प्रकट करता है: क्वेरी तैयार करने वाले के पास आपके SQL प्रश्नों के प्रदर्शन की कुंजी भी होती है। यदि ऑप्टिमाइज़र को खराब रूप से तैयार अनुरोध प्राप्त होता है, तो वह उतना ही कर सकता है ...

इसका मतलब है कि कुछ चीजें हैं जो आप अनुरोध लिखते समय कर सकते हैं। जैसा कि आप पहले से ही परिचय में देख चुके हैं, यहां जिम्मेदारी दो गुना है: यह न केवल उन प्रश्नों को लिखने के बारे में है जो एक निश्चित मानक को पूरा करते हैं, बल्कि उन विचारों को एकत्र करने के बारे में भी हैं जहां आपकी क्वेरी में प्रदर्शन समस्याएं छिपी हो सकती हैं।

एक आदर्श शुरुआती बिंदु आपके प्रश्नों में "स्थानों" के बारे में सोचना है जहां समस्याएं उत्पन्न हो सकती हैं। और, सामान्य तौर पर, चार कीवर्ड होते हैं जिसमें नए लोग प्रदर्शन समस्याओं की उम्मीद कर सकते हैं:

• हालत WHERE ;
• कोई कीवर्ड INNER JOIN या LEFT JOIN ; और भी
• HAVING स्थिति;

बेशक, यह दृष्टिकोण सरल और भोला है, लेकिन, एक शुरुआत के लिए, ये बिंदु उत्कृष्ट संकेत हैं, और यह कहना सुरक्षित है कि जब आप पहली बार शुरू करते हैं, तो इन जगहों पर त्रुटियां होती हैं और, अजीब तरह से पर्याप्त होती हैं, जहां नोटिस करना भी मुश्किल होता है।

हालांकि, आपको यह भी समझना चाहिए कि प्रदर्शन कुछ ऐसा है जो सार्थक होना चाहिए। हालाँकि, केवल यह कहना कि ये वाक्य और कीवर्ड बुरे हैं, जब आपको SQL प्रदर्शन के बारे में सोचना है, तो आपको इसकी आवश्यकता नहीं है। एक अनुरोध में WHERE या HAVING मतलब यह नहीं है कि यह एक बुरा अनुरोध है ...

अपनी क्वेरी बनाने के लिए एंटीपार्टर्न और वैकल्पिक तरीकों के बारे में अधिक जानने के लिए अगले भाग को देखें। ये टिप्स और ट्रिक्स एक गाइड के रूप में हैं। कैसे और अगर आपको वास्तव में आपके अनुरोध को फिर से लिखने की आवश्यकता है, तो डेटा की मात्रा, डेटाबेस, और अनुरोध को पूरा करने के लिए जितनी बार आवश्यकता होती है, उस पर निर्भर करता है। यह पूरी तरह से आपके अनुरोध के उद्देश्य पर निर्भर करता है और जिस डेटाबेस के साथ आप काम करेंगे उसके बारे में कुछ पूर्व ज्ञान होना महत्वपूर्ण है!

1. केवल आवश्यक डेटा प्राप्त करें

निष्कर्ष "अधिक डेटा, बेहतर" - एसक्यूएल लिखते समय पालन करने की आवश्यकता नहीं होती है: आप वास्तव में ज़रूरत से ज़्यादा डेटा प्राप्त करके न केवल भ्रमित हो रहे हैं, बल्कि प्रदर्शन को नुकसान हो सकता है क्योंकि आपकी क्वेरी बहुत अधिक डेटा प्राप्त करती है।

यही कारण है कि, एक नियम के रूप में, आपको SELECT , DISTINCT SELECT और LIKE स्टेटमेंट पर ध्यान देना चाहिए।

SELECT

जब आप कोई प्रश्न लिखते हैं, तो पहली बात यह जांच सकते हैं कि क्या SELECT यथासंभव कॉम्पैक्ट है। यहां का लक्ष्य SELECT से अनावश्यक कॉलम हटाने का होना चाहिए। इस तरह आप अपने आप को केवल उन डेटा को पुनः प्राप्त करने के लिए मजबूर करते हैं जो आपके क्वेरी उद्देश्य को पूरा करते हैं।

यदि आपने EXISTS साथ सह-सम्बन्ध स्थापित किए हैं, तो आपको वास्तविक स्तंभ का मान चुनने के बजाय इस उप-धारा के SELECT में एक स्थिरांक का उपयोग करने का प्रयास करना चाहिए। यह विशेष रूप से सुविधाजनक है जब आप केवल अस्तित्व की जांच करते हैं।

याद रखें कि सहसंबंधित उपशम एक उपश्रेणी है जो बाहरी क्वेरी से मानों का उपयोग करता है। और ध्यान दें कि भले ही NULL इस संदर्भ में "स्थिर" के रूप में काम कर सकता है, लेकिन यह बहुत भ्रामक है!

स्थिरांक का उपयोग करके क्या मतलब है यह समझने के लिए निम्नलिखित उदाहरण पर विचार करें:

 SELECT driverslicensenr, name FROM Drivers WHERE EXISTS (SELECT '1' FROM Fines WHERE fines.driverslicensenr = drivers.driverslicensenr); 

युक्ति: यह जानना उपयोगी है कि सहसंबंधित उपवर्ग होना हमेशा एक अच्छा विचार नहीं है। आप हमेशा उनसे छुटकारा पाने पर विचार कर सकते हैं, उदाहरण के लिए, उन्हें INNER JOIN का उपयोग करके फिर से लिखना:

 SELECT driverslicensenr, name FROM drivers INNER JOIN fines ON fines.driverslicensenr = drivers.driverslicensenr; 

ऑपरेशन DISTINCT

SELECT DISTINCT उपयोग केवल भिन्न मानों को वापस करने के लिए किया जाता है। DISTINCT एक बिंदु है जिसे यदि संभव हो तो निश्चित रूप से टाला जाना चाहिए। अन्य उदाहरणों की तरह, निष्पादन का समय केवल तभी बढ़ता है जब यह वाक्य अनुरोध में जोड़ा जाता है। इसलिए, यह विचार करना हमेशा उपयोगी होता है कि क्या परिणाम प्राप्त करने के लिए आपको वास्तव में इस DISTINCT ऑपरेशन की आवश्यकता है।

LIKE स्टेटमेंट

किसी क्वेरी में LIKE ऑपरेटर का उपयोग करते समय, यदि पैटर्न % या _ शुरू होता है तो इंडेक्स का उपयोग नहीं किया जाता है। यह डेटाबेस को इंडेक्स (यदि कोई मौजूद है) का उपयोग करने से रोकेगा। बेशक, दूसरे दृष्टिकोण से, यह भी तर्क दिया जा सकता है कि इस प्रकार का अनुरोध संभावित रूप से बहुत सारे रिकॉर्ड प्राप्त करना संभव बनाता है जो अनुरोध के उद्देश्य को पूरा नहीं करते हैं।

फिर से, डेटाबेस में संग्रहीत डेटा को जानने से आपको एक टेम्पलेट तैयार करने में मदद मिल सकती है, जो केवल उन पंक्तियों को खोजने के लिए सभी डेटा को सही ढंग से फ़िल्टर करेगा जो वास्तव में आपकी क्वेरी के लिए महत्वपूर्ण हैं।

2. अपने परिणाम सीमित करें

यदि आप अपने SELECT फ़िल्टर करने से बच नहीं सकते हैं, तो आप अपने परिणामों को अन्य तरीकों से सीमित कर सकते हैं। यह वह जगह है जहां LIMIT और डेटा प्रकार रूपांतरण जैसे दृष्टिकोण आते हैं।

TOP , LIMIT और ROWNUM

परिणाम सेट के लिए अधिकतम पंक्तियों को निर्दिष्ट करने के लिए आप प्रश्नों में LIMIT या TOP स्टेटमेंट जोड़ सकते हैं। यहाँ कुछ उदाहरण हैं:

  SELECT TOP 3 * FROM Drivers; 

ध्यान दें कि आप वैकल्पिक रूप से PERCENT निर्दिष्ट कर सकते हैं, उदाहरण के लिए, यदि आप SELECT TOP 50 PERCENT * साथ पहली क्वेरी लाइन बदलते हैं।

 SELECT driverslicensenr, name FROM Drivers LIMIT 2; 

वैकल्पिक रूप से, आप क्वेरी में LIMIT का उपयोग करने के लिए ROWNUM को जोड़ सकते हैं:

 SELECT * FROM Drivers WHERE driverslicensenr = 123456 AND ROWNUM <= 3; 

डेटा प्रकार रूपांतरण

सबसे प्रभावी हमेशा उपयोग किया जाना चाहिए, अर्थात् सबसे छोटा, डेटा प्रकार। जब आप एक विशाल डेटा प्रकार प्रदान करते हैं तो हमेशा एक जोखिम होता है, जबकि एक छोटा एक अधिक पर्याप्त होगा।

हालाँकि, जब आप क्वेरी में डेटा प्रकार रूपांतरण जोड़ते हैं, तो केवल निष्पादन समय बढ़ता है।

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

3. प्रश्नों को जितना जटिल होना चाहिए उससे अधिक जटिल मत बनाओ

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

हालांकि, निम्नलिखित अनुभागों में वर्णित उदाहरणों में, आप देखेंगे कि आप आसानी से सरल प्रश्नों को अधिक जटिल बनाना शुरू कर सकते हैं जितना उन्हें होना चाहिए।

OR ऑपरेटर

जब आप अपनी क्वेरी में OR ऑपरेटर का उपयोग करते हैं, तो सबसे अधिक संभावना है कि आप एक इंडेक्स का उपयोग नहीं कर रहे हैं।

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

यदि आप डेटाबेस में शामिल अनुक्रमित का उपयोग नहीं करते हैं, तो आपकी क्वेरी का निष्पादन अनिवार्य रूप से अधिक समय लेगा। यही कारण है कि आपकी क्वेरी में OR ऑपरेटर का उपयोग करने के लिए विकल्पों की तलाश करना सबसे अच्छा है;

निम्नलिखित प्रश्न पर विचार करें:

 SELECT driverslicensenr, name FROM Drivers WHERE driverslicensenr = 123456 OR driverslicensenr = 678910 OR driverslicensenr = 345678; 

ऑपरेटर द्वारा प्रतिस्थापित किया जा सकता है:

IN साथ शर्त; या

 SELECT driverslicensenr, name FROM Drivers WHERE driverslicensenr IN (123456, 678910, 345678); 

UNION साथ दो SELECT ।

युक्ति: यहां आपको अनावश्यक UNION ऑपरेशन का उपयोग न करने के लिए सावधान रहना होगा, क्योंकि आप एक ही तालिका को कई बार देख रहे हैं। उसी समय, आपको यह समझना चाहिए कि जब आप अपनी क्वेरी में UNION का उपयोग करते हैं, तो निष्पादन समय बढ़ जाता है। UNION ऑपरेशन के विकल्प: क्वेरी में सुधार करें ताकि सभी शर्तों को एक एकल SELECT में रखा जाए, या UNION बजाय OUTER JOIN उपयोग करें।

युक्ति: इस बात का ध्यान रखें कि OR - और अन्य ऑपरेटर जिनका उल्लेख निम्नलिखित वर्गों में किया जाएगा - सबसे अधिक संभावना है कि एक इंडेक्स का उपयोग न करें, इंडेक्स सर्च हमेशा बेहतर नहीं होता है!

संचालक NOT

जब आपकी क्वेरी में एक ऑपरेटर NOT होता है, तो यह संभावना है कि सूचकांक का उपयोग नहीं किया जाता है, जैसा कि OR ऑपरेटर के साथ है। यह अनिवार्य रूप से आपके अनुरोध को धीमा कर देगा। यदि आपको नहीं पता कि यहां क्या है, तो निम्नलिखित प्रश्न पर विचार करें:

 SELECT driverslicensenr, name FROM Drivers WHERE NOT (year > 1980); 

यह क्वेरी निश्चित रूप से धीमी गति से चलेगी जितना आप उम्मीद कर सकते हैं, मुख्य रूप से क्योंकि यह इसकी तुलना में बहुत अधिक जटिल है: यह इस तरह के मामलों में, एक विकल्प की तलाश में सबसे अच्छा है। तुलना संचालकों जैसे > , <> या !> NOT प्रतिस्थापित करने पर विचार करें; उपरोक्त उदाहरण वास्तव में फिर से लिखा जा सकता है और कुछ इस तरह दिख सकता है:

 SELECT driverslicensenr, name FROM Drivers WHERE year <= 1980; 

यह पहले से ही बेहतर है, है ना?

AND ऑपरेटर

AND ऑपरेटर एक अन्य ऑपरेटर है जो किसी इंडेक्स का उपयोग नहीं करता है और जो क्वेरी को धीमा कर सकता है यदि इसका उपयोग अत्यधिक जटिल और अक्षम तरीके से किया जाता है, जैसा कि निम्नलिखित उदाहरण में है:

 SELECT driverslicensenr, name FROM Drivers WHERE year >= 1960 AND year <= 1980; 

बेहतर है कि इस कथन को फिर से लिखना कथन का उपयोग करके फिर से BETWEEN :

 SELECT driverslicensenr, name FROM Drivers WHERE year BETWEEN 1960 AND 1980; 

ANY और ALL ऑपरेटर

इसके अलावा, ANY और ALL ऑपरेटर वे हैं जिनसे आपको सावधान रहना चाहिए, क्योंकि यदि आप उन्हें अपने प्रश्नों में शामिल करते हैं, तो सूचकांक का उपयोग नहीं किया जाएगा। वैकल्पिक एकत्रीकरण कार्य जैसे कि MIN या MAX यहां उपयोगी हैं।

युक्ति: जब आप प्रस्तावित विकल्पों का उपयोग करते हैं, तो आपको पता होना चाहिए कि सभी एकत्रीकरण कार्य, जैसे कि SUM , AVG , MIN , MAX कई लाइनों से अधिक लंबी क्वेरी के लिए नेतृत्व कर सकते हैं। ऐसे मामलों में, आप इन मानों को संसाधित या पूर्व-गणना करने के लिए पंक्तियों की संख्या को कम करने का प्रयास कर सकते हैं। एक बार फिर आप देखते हैं कि आपके पर्यावरण, आपके अनुरोध के उद्देश्य के बारे में जानना महत्वपूर्ण है, ... जब आप तय करते हैं कि किस अनुरोध का उपयोग करना है!

स्थितियों में स्तंभों को अलग करें

इसके अलावा, ऐसे मामलों में जहां एक स्तंभ का उपयोग गणना या स्केलर फ़ंक्शन में किया जाता है, सूचकांक का उपयोग नहीं किया जाता है। एक संभावित समाधान केवल एक विशिष्ट कॉलम का चयन करना होगा ताकि यह गणना या फ़ंक्शन का हिस्सा न हो। निम्नलिखित उदाहरण पर विचार करें:

 SELECT driverslicensenr, name FROM Drivers WHERE year + 10 = 1980; 

यह अजीब लग रहा है, हुह? इसके बजाय, गणना को संशोधित करने का प्रयास करें और इस तरह से क्वेरी को फिर से लिखें:

 SELECT driverslicensenr, name FROM Drivers WHERE year = 1970; 

4. पाशविक बल का अभाव

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

जॉइन में टेबल ऑर्डर

जब दो तालिकाओं को जोड़ते हैं, तो जुड़ने में तालिकाओं के क्रम पर विचार करना महत्वपूर्ण हो सकता है। यदि आप देखते हैं कि एक तालिका दूसरे की तुलना में काफी बड़ी है, तो आपको क्वेरी को फिर से लिखने की आवश्यकता हो सकती है ताकि सबसे बड़ी तालिका को अंतिम में शामिल किया जाए।

अत्यधिक कनेक्शन की स्थिति

यदि आप SQL कनेक्शन में बहुत अधिक शर्तें जोड़ते हैं, तो आपको एक विशिष्ट पथ चुनना होगा। हालाँकि, यह हो सकता है कि यह मार्ग हमेशा अधिक कुशल न हो।

HAVING की स्थिति

HAVING मूल रूप से SQL में जोड़ा गया था क्योंकि WHERE कीवर्ड को कुल कार्यों के साथ उपयोग नहीं किया जा सकता था। HAVING उपयोग आम तौर पर उन पंक्तियों के समूहों को प्रतिबंधित करने के लिए GROUP BY साथ किया जाता है जो कुछ शर्तों को पूरा करते हैं। हालाँकि, यदि इस स्थिति का उपयोग क्वेरी में किया जाता है, तो इंडेक्स का उपयोग नहीं किया जाता है, जो कि आप पहले से ही जानते हैं, इस तथ्य को जन्म दे सकता है कि क्वेरी वास्तव में इतनी अच्छी तरह से काम नहीं करती है।

यदि आप एक विकल्प की तलाश कर रहे हैं, तो WHERE का उपयोग करके देखें।

निम्नलिखित प्रश्नों पर विचार करें:

 SELECT state, COUNT(*) FROM Drivers WHERE state IN ('GA', 'TX') GROUP BY state ORDER BY state 

 SELECT state, COUNT(*) FROM Drivers GROUP BY state HAVING state IN ('GA', 'TX') ORDER BY state 

पहली क्वेरी WHERE का उपयोग उन पंक्तियों की संख्या को सीमित करने के लिए करती है, जिन्हें संक्षेप में प्रस्तुत करने की आवश्यकता होती है, जबकि दूसरी क्वेरी तालिका में सभी पंक्तियों को HAVING , और फिर गणना की गई मात्राओं को छोड़ने के लिए HAVING का उपयोग करती है। ऐसे मामलों में, WHERE आप संसाधनों को बर्बाद नहीं कर रहे हैं, वहां WHERE विकल्प स्पष्ट रूप से बेहतर है।

यह देखा जा सकता है कि यह परिणाम सेट को सीमित करने के बारे में नहीं है, बल्कि क्वेरी में रिकॉर्ड की मध्यवर्ती संख्या को सीमित करने के बारे में है।

यह ध्यान दिया जाना चाहिए कि दो स्थितियों के बीच का अंतर यह है कि WHERE व्यक्तिगत पंक्तियों के लिए एक शर्त पेश करता है, जबकि HAVING एकत्रीकरण या चयन परिणामों के लिए एक शर्त पेश करता है, जहां एक परिणाम, जैसे MIN , MAX , SUM , ... कई लाइनों से बनाया गया।

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

यह सूची कुछ एंटीपर्टर्न और युक्तियों का एक छोटा सा अवलोकन थी जो मुझे आशा है कि शुरुआती लोगों की मदद करेंगे; यदि आप इस बात का अंदाजा लगाना चाहते हैं कि पुराने डेवलपर्स सबसे सामान्य विरोधी पैटर्न पर क्या विचार करते हैं, तो इस चर्चा को देखें

प्रश्नों को लिखने के लिए सेट-आधारित बनाम प्रक्रियात्मक दृष्टिकोण

उपर्युक्त एंटीपैटर्नस ने निहित किया कि वे वास्तव में आपके प्रश्नों के निर्माण के लिए सेट-आधारित और प्रक्रियात्मक दृष्टिकोण में अंतर पर आते हैं।

प्रश्नों के लिए प्रक्रियात्मक दृष्टिकोण प्रोग्रामिंग के समान है: आप सिस्टम को बताते हैं कि क्या करना है और कैसे करना है।

इसका एक उदाहरण कनेक्शन या मामलों में अत्यधिक शर्तों है जब आप HAVING शर्तों का दुरुपयोग करते हैं, जैसा कि ऊपर दिए गए उदाहरणों में है, जिसमें आप किसी फ़ंक्शन को निष्पादित करके एक डेटाबेस को क्वेरी करते हैं और फिर किसी अन्य फ़ंक्शन को कॉल करते हैं, या आप तर्क का उपयोग करते हैं जिसमें शर्तों, लूप, उपयोगकर्ता-परिभाषित फ़ंक्शन शामिल होते हैं UDF), कर्सर, ... अंतिम परिणाम प्राप्त करने के लिए। इस दृष्टिकोण के साथ, आप अक्सर डेटा के सबसेट का अनुरोध करेंगे, फिर डेटा के किसी अन्य सबसेट का अनुरोध करें, और इसी तरह।

अप्रत्याशित रूप से, इस दृष्टिकोण को अक्सर "चरण-दर-चरण" या "लाइन-बाय-लाइन" क्वेरी कहा जाता है।

एक अन्य दृष्टिकोण एक सेट-आधारित दृष्टिकोण है, जहां आप बस संकेत देते हैं कि क्या करना है। आपकी भूमिका उस परिणाम सेट के लिए शर्तों या आवश्यकताओं को निर्दिष्ट करना है जो आप क्वेरी से प्राप्त करना चाहते हैं। आप अपने डेटा को उस तरीके से छोड़ देते हैं जो आंतरिक तंत्र को क्वेरी के कार्यान्वयन को निर्धारित करता है: आप डेटाबेस इंजन को अपनी क्वेरी को निष्पादित करने के लिए सबसे अच्छा एल्गोरिदम या प्रसंस्करण तर्क निर्धारित करते हैं।

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

सलाह एक सेट- आधारित तरीका है जिसमें क्वेरी करना भी एक है जो सूचना प्रौद्योगिकी उद्योग में सबसे अग्रणी नियोक्ता आपको मास्टर करने के लिए कहेंगे! इन दो प्रकार के दृष्टिकोणों के बीच स्विच करना अक्सर आवश्यक होता है।

कृपया ध्यान दें कि यदि आपको कभी प्रक्रियात्मक अनुरोध की आवश्यकता होती है, तो आपको इसे फिर से लिखने या फिर से तैयार करने पर विचार करना चाहिए।

अगला भाग योजना और क्वेरी अनुकूलन को कवर करेगा।