अंतर सूक्ष्म, कभी-कभी महत्वपूर्ण, और कभी-कभी प्रभावी रूप से अस्तित्वहीन हो सकते हैं।
सामान्य तौर पर एक तैयार कथन 1. सर्वर के साथ तैयार हो जाता है (एसक्यूएल पार्स, निष्पादन योजना उत्पन्न, आदि), 2. अतिरिक्त पैरामीटर के साथ निष्पादित किया जाता है, और फिर 3. बंद कर दिया जाता है। यह आपको हर बार पारित विभिन्न मापदंडों के साथ एक ही एसक्यूएल का पुन:उपयोग करने देता है, यह एसक्यूएल इंजेक्शन के खिलाफ सुरक्षा में मदद कर सकता है, कुछ प्रदर्शन संवर्द्धन (ड्राइवर/प्रोटोकॉल विशिष्ट, वाईएमएमवी) प्रदान कर सकता है और निष्पादन योजना निर्माण और एसक्यूएल पार्सिंग में दोहराए गए चरणों को रोक सकता है। तैयार करें ऊपर कदम।
स्रोत कोड लिखने वाले किसी व्यक्ति के लिए तैयार कथन स्ट्रिंग्स को जोड़ने और उन्हें डीबी सर्वर पर भेजने से अधिक सुविधाजनक हो सकता है।
DB.Query() विधि SQL को एक स्ट्रिंग के रूप में लेती है, और शून्य या अधिक तर्क (जैसा कि Exec() करता है) , या QueryRow() ) बिना किसी अतिरिक्त तर्क के एक SQL स्ट्रिंग ठीक वही पूछेगी जो आपने लिखा था। हालांकि, प्लेसहोल्डर्स और अतिरिक्त तर्कों के साथ एक SQL स्ट्रिंग प्रदान की गई, हुड के तहत आपके लिए एक तैयार कथन किया जा रहा है।
DB.Prepare() विधि स्पष्ट रूप से एक तैयार कथन निष्पादित करती है, जिसे आप तब तर्क देते हैं, जैसे:stmt.Exec(...args) ।
दोनों के बीच अंतर और एक या दूसरे का उपयोग क्यों करना है, इसके बारे में सोचने लायक कुछ चीजें हैं।
आप DB.Query() . का उपयोग कर सकते हैं बिना तर्क के। यह बहुत कुशल हो सकता है क्योंकि यह तैयार करें --> निष्पादित करें --> बंद करें . को बायपास कर सकता है अनुक्रम है कि तैयार बयान अनिवार्य रूप से गुजरता है।
आप इसे अतिरिक्त तर्कों और क्वेरी स्ट्रिंग में प्लेसहोल्डर के साथ भी उपयोग कर सकते हैं, और यह कवर के तहत तैयार किए गए कथन को निष्पादित करेगा जैसा कि मैंने ऊपर उल्लेख किया है। यहां संभावित समस्या यह है कि जब आप कई प्रश्न कर रहे होते हैं, तो प्रत्येक के परिणामस्वरूप एक अंडर-द-हूड तैयार कथन होता है। चूंकि इसमें अतिरिक्त कदम शामिल हैं, यह बल्कि अक्षम हो सकता है क्योंकि यह हर बार जब आप उस क्वेरी को फिर से तैयार करते हैं, निष्पादित करते हैं और बंद करते हैं।
स्पष्ट रूप से तैयार किए गए कथन के साथ आप संभवतः उस अक्षमता से बच सकते हैं क्योंकि आप संभावित रूप से भिन्न तर्कों के साथ पहले तैयार किए गए SQL का पुन:उपयोग करने का प्रयास कर रहे हैं।
लेकिन यह हमेशा वैसा काम नहीं करता जैसा आप उम्मीद कर सकते हैं... डीबी/एसक्यूएल द्वारा प्रबंधित अंतर्निहित कनेक्शन पूल के कारण, आपका "डेटाबेस कनेक्शन" काफी आभासी है। DB.Prepare() विधि एक विशेष कनेक्शन के खिलाफ बयान तैयार करेगी और फिर उसी कनेक्शन को वापस पाने का प्रयास करेगी जब यह निष्पादित करने का समय हो, लेकिन यदि वह कनेक्शन अनुपलब्ध है तो यह केवल उपलब्ध एक को पकड़ लेगा और फिर से तैयार करेगा और उसके खिलाफ निष्पादित करेगा। यदि आप उसी तैयार किए गए कथन का बार-बार उपयोग कर रहे हैं, तो हो सकता है कि आप अनजाने में भी उसे बार-बार तैयार कर रहे हों। यह स्पष्ट रूप से अधिकतर तब सामने आता है जब आप भारी ट्रैफ़िक से निपट रहे होते हैं।
तो जाहिर है कि आप किस परिस्थिति में उपयोग करते हैं, यह आपके विशिष्ट उपयोग के मामले पर निर्भर करता है, लेकिन मुझे आशा है कि ऊपर दिए गए विवरण आपके लिए पर्याप्त रूप से स्पष्ट कर देंगे कि आप प्रत्येक मामले में सबसे अच्छा निर्णय ले सकते हैं।
अपडेट करें
ओपी में अद्यतन को देखते हुए अनिवार्य रूप से कोई अंतर नहीं है जब क्वेरी को केवल एक बार निष्पादित करने की आवश्यकता होती है, क्योंकि तर्कों के साथ प्रश्नों को पर्दे के पीछे तैयार बयान के रूप में किया जाता है।
प्रत्यक्ष विधियों का प्रयोग करें, उदा। DB.Query() और इसके एनालॉग्स, बनाम स्पष्ट रूप से तैयार किए गए कथनों का उपयोग करना, क्योंकि इसका परिणाम कुछ सरल स्रोत कोड में होगा।
चूंकि तैयार किए गए बयान, इस मामले में, सुरक्षा कारणों से उपयोग किए जा रहे हैं, यह अन्य तरीकों से सुरक्षा चिंताओं को संभालने के प्रयास के लायक हो सकता है और इसके बजाय सादे टेक्स्ट प्रश्नों का उपयोग कर सकता है, क्योंकि इससे प्रदर्शन में सुधार होगा। हालांकि, कोई भी लाभ तब तक अप्रासंगिक हो सकता है जब तक कि सर्वर पर लोड को कम करने के लिए पर्याप्त ट्रैफ़िक (या भविष्य में ट्रैफ़िक के काफी बढ़ने की भविष्यवाणी नहीं की जाती) न हो। फिर से यह वास्तविक दुनिया के उपयोग के मामले में आता है।
तैयार किए गए कथनों और सीधे सादे पाठ प्रश्नों के बीच अंतर पर कुछ मीट्रिक में रुचि रखने वाले किसी भी व्यक्ति के लिए, एक अच्छा लेख है यहां (जो उपरोक्त में से बहुत कुछ समझाने का एक उत्कृष्ट कार्य भी करता है)।
