डायनेमिक SQL और संग्रहीत कार्यविधियाँ SQL सर्वर के दो सबसे महत्वपूर्ण घटक हैं। इस लेख में, हम उनमें से प्रत्येक के फायदे और नुकसान को देखेंगे और उनका उपयोग कब करेंगे।
प्रदर्शन
इस सवाल का जवाब सभी जानते हैं। प्रदर्शन के मामले में संग्रहीत कार्यविधियाँ गतिशील SQL को हरा देती हैं। एक संग्रहीत कार्यविधि को सर्वर मेमोरी में कैश किया जाता है और इसका निष्पादन डायनेमिक SQL की तुलना में बहुत तेज़ होता है। यदि सभी शेष चर स्थिर रखे जाते हैं, तो संग्रहीत कार्यविधि गतिशील SQL से बेहतर प्रदर्शन करती है।
चिंताओं का पृथक्करण
चिंताओं को अलग करने के संदर्भ में, संग्रहीत कार्यविधियाँ गतिशील SQL को पीछे छोड़ देती हैं।
संग्रहीत कार्यविधियाँ आपको अपने डेटाबेस तर्क को अपने व्यावसायिक तर्क से अलग रखने की अनुमति देती हैं। इसलिए, यदि आपके व्यावसायिक तर्क में कोई त्रुटि होती है, तो आपको केवल अपना आवेदन कोड बदलना होगा। इसके विपरीत, यदि आपके डेटाबेस लॉजिक में कोई समस्या है, तो केवल आपकी संग्रहीत कार्यविधि को संशोधित करने की आवश्यकता है। इसके अतिरिक्त, यदि संग्रहीत कार्यविधि को अद्यतन किया जाता है, तो एप्लिकेशन कोड को पुन:संकलित और परिनियोजित करने की आवश्यकता नहीं है।
यदि आप अपने क्लाइंट कोड में डायनेमिक SQL क्वेरी का उपयोग करते हैं, तो SQL क्वेरी में कोई त्रुटि होने पर आपको एप्लिकेशन कोड अपडेट करना होगा। इसका मतलब है कि आपको एप्लिकेशन कोड को फिर से संकलित और परिनियोजित करना होगा।
नेटवर्क ट्रैफ़िक
संग्रहीत कार्यविधियाँ गतिशील SQL की तुलना में कम नेटवर्क ट्रैफ़िक उत्पन्न करती हैं क्योंकि संग्रहीत कार्यविधि को निष्पादित करने के लिए केवल प्रक्रिया नाम और पैरामीटर (यदि कोई हो) को नेटवर्क पर भेजने की आवश्यकता होती है।
डायनेमिक SQL को निष्पादित करने के लिए संपूर्ण क्वेरी को पूरे नेटवर्क में भेजने की आवश्यकता होती है, जिससे नेटवर्क ट्रैफ़िक बढ़ता है, खासकर यदि क्वेरी बहुत बड़ी हो।
SQL इंजेक्शन अटैक
संग्रहीत कार्यविधियाँ SQL इंजेक्शन हमलों के लिए असुरक्षित नहीं हैं।
यदि पैरामीटरयुक्त क्वेरी का उपयोग नहीं किया जाता है, तो डायनेमिक SQL क्वेरीज़ SQL इंजेक्शन हमलों के लिए असुरक्षित होती हैं, और यदि पैरामीटर के रूप में तालिका या कॉलम नाम पास किया जाता है, तो पैरामीटरयुक्त क्वेरीज़ का उपयोग डायनेमिक SQL के साथ नहीं किया जा सकता है।
इस मामले में, समाधान यह है कि कोड नाम फ़ंक्शन का उपयोग SQL इंजेक्शन हमलों को रोकने के लिए किया जा सकता है।
कैश्ड क्वेरी योजनाओं की पुन:प्रयोज्यता
संग्रहीत कार्यविधियाँ डेटाबेस के प्रदर्शन में सुधार करती हैं क्योंकि वे कैश्ड क्वेरी योजनाओं को पुन:उपयोग करने की अनुमति देती हैं। डायनेमिक SQL के मामले में, कैश्ड क्वेरी प्लान पुन:प्रयोज्य को बढ़ाने के लिए आपको पैरामीटरयुक्त क्वेरी का उपयोग करना होगा। पैरामीटरयुक्त क्वेरी योजनाओं की अनुपस्थिति में, SQL सर्वर स्वचालित रूप से पैरामीटर का पता लगाता है और कैश्ड क्वेरी प्लान उत्पन्न करता है जिसके परिणामस्वरूप बेहतर प्रदर्शन होता है।
यहां यह उल्लेख करना उचित है कि कैश्ड क्वेरी प्लान पुन:प्रयोज्य से केवल OLTP सिस्टम ही लाभान्वित होते हैं। OLAP सिस्टम के मामले में, ऑप्टिमाइज़र का विकल्प बदल जाता है, OLAP सिस्टम अद्वितीय योजना से लाभान्वित होता है।
रखरखाव
स्थिर SQL के साथ संग्रहीत कार्यविधियाँ बनाए रखना आसान है। उदाहरण के लिए, एक संग्रहीत कार्यविधि में स्थिर SQL के मामले में, सिंटैक्स त्रुटियों को चलाने से पहले पकड़ा जा सकता है। संग्रहीत कार्यविधियों के अंदर गतिशील SQL के मामले में, क्वेरी निष्पादन से पहले सिंटैक्स त्रुटियों को नहीं पकड़ा जा सकता है।
इसके अलावा, संग्रहीत प्रक्रियाएं कार्यों की तरह अधिक होती हैं, उन्हें एक बार परिभाषित किया जाता है और फिर स्क्रिप्ट में कहीं भी कहा जा सकता है। इसलिए, यदि आप किसी संग्रहीत कार्यविधि को अद्यतन करना चाहते हैं, तो आपको उसे केवल एक ही स्थान पर अद्यतन करना होगा। संग्रहीत कार्यविधि को कॉल करने वाले सभी एप्लिकेशन भागों के पास अद्यतन संस्करण तक पहुंच होगी। हालाँकि, एक नकारात्मक पहलू यह है कि वे अनुप्रयोग भाग भी प्रभावित हो सकते हैं जहाँ आप अद्यतन संग्रहीत कार्यविधि नहीं चाहते हैं। डायनेमिक एसक्यूएल के मामले में आपको कई जगहों पर एसक्यूएल स्क्रिप्ट लिखनी पड़ सकती है, लेकिन ऐसे मामलों में, एक जगह पर स्क्रिप्ट को अपडेट करने से दूसरी जगह प्रभावित नहीं होती है। संग्रहीत कार्यविधि और डायनेमिक SQL का उपयोग करने के बीच का निर्णय एप्लिकेशन की कार्यक्षमता पर निर्भर करता है।
सुरक्षा
यदि एकाधिक अनुप्रयोग डेटाबेस तक पहुँचते हैं, तो गतिशील SQL की तुलना में संग्रहीत कार्यविधियों का उपयोग करना अधिक सुरक्षित होता है।
संग्रहीत कार्यविधियाँ सुरक्षा की एक अतिरिक्त परत प्रदान करती हैं, जबकि उपयोगकर्ता संदर्भ गतिशील SQL स्क्रिप्ट पर अनुमतियों को नियंत्रित करने का एकमात्र तरीका है। कुल मिलाकर, संग्रहीत कार्यविधियों की तुलना में गतिशील SQL को सुरक्षित करना श्रमसाध्य है।
निर्भरता की पहचान करना
एक रिलेशनल डेटाबेस में, टेबल की डेटाबेस में अन्य टेबल पर निर्भरता होती है।
एक ऐसे परिदृश्य पर विचार करें जहां आप एक तालिका को हटाना चाहते हैं, लेकिन ऐसा करने से पहले, आप सभी तालिका निर्भरताओं का पता लगाना चाहते हैं। या सरल शब्दों में, आप उन प्रश्नों को खोजना चाहते हैं जो उस तालिका तक पहुँचते हैं जिसे आप हटाना चाहते हैं। इन मामलों में, आप उपयोग कर सकते हैं sp_depends संग्रहीत कार्यविधि।
हालांकि, sp_depends केवल उन निर्भरताओं का पता लगा सकता है जहां संग्रहीत प्रक्रिया के अंदर स्थिर SQL का उपयोग किया जाता है। डायनेमिक SQL के किसी तालिका पर निर्भर होने की स्थिति में, उस निर्भरता का पता नहीं लगाया जा सकता है sp_depends संग्रहीत कार्यविधि। आइए इसे एक सरल उदाहरण की सहायता से क्रिया में देखें।
डमी डेटा तैयार करना
आइए स्थिर और गतिशील SQL में निर्भरता की अवधारणा को समझाने में मदद करने के लिए कुछ डमी डेटा बनाएं।
CREATE DATABASE deptest; USE deptest CREATE TABLE student ( Id int identity primary key, Name VARCHAR(50) NOT NULL, Gender VARCHAR(50) NOT NULL, Age int ) INSERT INTO student VALUES ('James', 'Male', 20), ('Helene', 'Female', 20), ('Sofia', 'Female', 20), ('Ed', 'Male', 20), ('Ron', 'Female', 20)
अब हमारे पास एक टेस्ट डेटाबेस है जिसमें एक टेबल और कुछ टेस्ट डेटा है। अब दो संग्रहीत कार्यविधियाँ बनाते हैं जो छात्र तालिका तक पहुँचती हैं।
छात्र तालिका से सभी रिकॉर्ड पुनर्प्राप्त करने के लिए पहली संग्रहीत प्रक्रिया स्थिर SQL का उपयोग करती है:
USE deptest GO CREATE PROC spStatProc AS BEGIN SELECT * FROM student END
उपरोक्त स्क्रिप्ट निष्पादित करें। यह स्क्रिप्ट सबसे अच्छे डेटाबेस के अंदर एक संग्रहित प्रक्रिया "spStatProc" बनाती है।
आइए एक और संग्रहीत कार्यविधि बनाएं जिसमें गतिशील SQL शामिल है जो छात्र तालिका से सभी रिकॉर्ड पुनर्प्राप्त करता है।
USE deptest GO CREATE PROC spDynProc AS BEGIN DECLARE @query NVARCHAR(100) SET @query = 'SELECT * FROM student' EXECUTE sp_execute @query END
यह स्क्रिप्ट सबसे अच्छे डेटाबेस के अंदर एक संग्रहित प्रक्रिया "spDynProc" बनाती है। यह संग्रहीत कार्यविधि छात्र तालिका से सभी रिकॉर्ड पुनर्प्राप्त करने के लिए एक गतिशील SQL कथन का उपयोग करती है।
अब हमारे पास दो संग्रहीत कार्यविधियाँ हैं जिनकी छात्र तालिका पर निर्भरता है। उनमें से एक में स्थिर SQL है और दूसरे में गतिशील SQL है।
हालाँकि, यदि आप sp_depends संग्रहीत कार्यविधि को निष्पादित करते हैं और इसे छात्र तालिका को एक पैरामीटर के रूप में पास करते हैं, तो आप देखेंगे कि यह केवल "spStatProc" संग्रहीत कार्यविधि को पुनः प्राप्त करेगा। ऐसा इसलिए है क्योंकि इसमें स्थिर SQL है। "spDynProc" संग्रहीत कार्यविधि पर ध्यान नहीं दिया जाएगा क्योंकि इसमें गतिशील SQL शामिल है।
निम्न स्क्रिप्ट निष्पादित करें।
USE deptest GO EXECUTE sp_depends student
इसे निम्न आउटपुट मिलेगा:
[टेबल आईडी=40 /]
आप देख सकते हैं कि sp_depends "spDynProc" निर्भरता की रिपोर्ट करने में सक्षम नहीं था और केवल "spStatProc" की सूचना दी थी।
जटिलता
यदि आप बड़ी संख्या में फ़िल्टर का उपयोग कर रहे हैं और फ़िल्टर के बीच कई AND और OR क्लॉज़ हैं, तो संग्रहीत कार्यविधियाँ अत्यंत जटिल हो सकती हैं। दूसरी ओर, डायनेमिक SQL का उपयोग करके आप फ़िल्टर के प्रकार के आधार पर गतिशील रूप से WHERE क्लॉज़ उत्पन्न कर सकते हैं। यदि आप अत्यंत जटिल तर्क को लागू करना चाहते हैं तो यह गतिशील SQL को बेहतर विकल्प बनाता है।
निष्कर्ष
कुल मिलाकर, संग्रहीत कार्यविधि लगभग सभी पहलुओं में गतिशील SQL से बेहतर प्रदर्शन करती है। वे तेज़, सुरक्षित और बनाए रखने में आसान हैं, और उन्हें कम नेटवर्क ट्रैफ़िक की आवश्यकता होती है। एक नियम के रूप में, संग्रहीत कार्यविधियों का उपयोग उन परिदृश्यों में किया जाना चाहिए जहां आपको अपने प्रश्नों को संशोधित करने की आवश्यकता नहीं है और आपके प्रश्न बहुत जटिल नहीं हैं। हालांकि, यदि आप अक्सर अपनी क्वेरी में तालिका के नाम, कॉलम नाम या पैरामीटर की संख्या बदलते हैं, तो इसकी सरल कार्यान्वयन रणनीति के कारण डायनेमिक SQL बेहतर विकल्प है।
उपयोगी लिंक
- डायनामिक SQL बनाम संग्रहीत कार्यविधियाँ
- डायनेमिक SQL से डरें नहीं
- उच्च प्रदर्शन संग्रहित प्रक्रियाओं का निर्माण
- संग्रहीत प्रक्रियाओं पर कक्षाएं