मैं तैयार बयानों के बारे में बहुत कुछ पढ़ रहा हूं और मैंने जो कुछ भी पढ़ा है, उनमें से कोई भी उनका उपयोग करने के डाउनसाइड्स के बारे में बात नहीं करता है। इसलिए, मैं सोच रहा हूं कि क्या कोई "ड्रैगन" स्पॉट हैं जो लोग अनदेखा करते हैं?क्या तैयार वक्तव्यों का उपयोग करने के लिए डाउनसाइड्स हैं?
तैयार कथन केवल एक पार्स और प्रीकंपिल्ड SQL कथन है जो निष्पादित किए जाने वाले बाध्य चर के लिए इंतजार कर रहा है।
कोई भी निष्पादित कथन जल्द या बाद में तैयार हो जाता है (इसे पार्स, अनुकूलित, संकलित और फिर निष्पादित करने की आवश्यकता है)।
एक तैयार कथन सिर्फ पार्सिंग, अनुकूलन और संकलन के परिणामों का पुन: उपयोग करता है।
आमतौर पर डेटाबेस सिस्टम क्वेरी तैयार करने पर कुछ समय बचाने के लिए किसी प्रकार का अनुकूलन का उपयोग करते हैं, भले ही आप तैयार प्रश्नों का उपयोग न करें।
Oracle, उदाहरण के लिए, जब कोई क्वेरी पार्सिंग पहली बार लाइब्रेरी कैश की जांच करता है, और यदि वही कथन पहले से ही पार्स किया गया है, तो यह इसके बजाय कैश निष्पादन योजना का उपयोग करता है।
मुझे लगता है कि इस उत्तर में तैयार बयान के साथ एक महत्वपूर्ण समस्या है, उदाहरण के लिए। कि पूछताछ के समय मौजूद डेटा आंकड़ों के अनुसार क्वेरी प्लान को अनुकूलित किया गया है, और जब क्वेरी निष्पादित की जाती है, तो भविष्य में इष्टतम नहीं हो सकता है। तो यह एक तैयार बयान का नकारात्मक पक्ष है। – egbokul
कुछ लेख इसी तरह के नकारात्मक पक्ष का उल्लेख करते हैं: https://medium.com/@devinburnette/be-prepared-7768d1a111e1 --- और --- https: //www.vividcortex।कॉम/ब्लॉग/2014/11/1/विश्लेषण-तैयार-कथन-प्रदर्शन-विविडकोर्टेक्स/ – MarsAndBack
आप केवल एक बार एक बयान का उपयोग करते हैं, या यदि आप स्वचालित रूप से गतिशील एसक्यूएल बयान उत्पन्न (और ठीक से या तो everythin बचने या निश्चित रूप से कह अपने मानकों को केवल सुरक्षित पात्रों है) तो आप तैयार बयानों उपयोग नहीं करना चाहिए।
बेशक, यह बेहद दुर्लभ है। मुझे सर्वर साइड पर तैयार कथन सामग्री केवल इनपुट स्वच्छता करने के लिए बहुत आसान लगता है। – Powerlord
एकमात्र नकारात्मक पक्ष जिसे मैं सोच सकता हूं वह यह है कि वे सर्वर पर स्मृति लेते हैं। यह ज्यादा नहीं है, लेकिन शायद कुछ किनारे के मामले हैं जहां यह एक समस्या होगी लेकिन मुझे किसी के बारे में सोचना मुश्किल है।
तैयार कथन बनाम गतिशील एसक्यूएल के साथ एक और छोटा मुद्दा है, और यह है कि उन्हें डीबग करना कठिन हो सकता है। गतिशील एसक्यूएल के साथ, आप हमेशा एक लॉग फ़ाइल में एक समस्या क्वेरी लिख सकते हैं और इसे सीधे सर्वर पर चला सकते हैं जैसे आपका प्रोग्राम इसे देखता है। तैयार बयान के साथ यह क्रैश डेटा से निर्धारित पैरामीटर के एक विशिष्ट सेट के साथ आपकी क्वेरी का परीक्षण करने के लिए थोड़ा और अधिक काम कर सकता है। लेकिन इतना अधिक नहीं, और अतिरिक्त सुरक्षा निश्चित रूप से लागत को औचित्य देती है।
कुछ परिस्थितियों में, डेटाबेस इंजन तैयार कथन का उपयोग करते समय एक निम्न क्वेरी योजना के साथ आ सकता है (क्योंकि यह खोज के लिए वास्तविक बाइंड मानों के बिना सही मान्यताओं को नहीं बना सकता है)।
उदा।
http://www.postgresql.org/docs/current/static/sql-prepare.html
पर "नोट्स" अनुभाग तो यह साथ और बयानों की तैयारी कर पता लगाने के लिए जो तेजी से होता है बिना अपने प्रश्नों का परीक्षण लायक हो सकता है। आदर्श रूप में, आप फिर से बयान के आधार पर निर्णय लेंगे कि तैयार बयानों का उपयोग करना है या नहीं, हालांकि सभी ओआरएम आपको ऐसा करने की अनुमति नहीं देंगे।
मुझे पता चला है कि तैयार पैटर्न के लिए सभी या कुछ भी नहीं पहुंचने का सबसे अच्छा पैटर्न है। डीबीएमएस हम में से अधिकांश की तुलना में अधिक स्मार्ट है, और अधिकांश समय की सबसे अच्छी योजना का पता लगा सकता है। साथ ही मुझे यकीन है कि आप जानते हैं कि विभिन्न डीबीएमएस में अलग-अलग क्वेरी प्लान रणनीतियों की आवश्यकता होगी, इसलिए लिंक को तैयार बयान के लिए कैच-ऑल के रूप में उपयोग नहीं किया जाना चाहिए। यदि आप वेब काम के लिए अपने डीबीएमएस का उपयोग कर रहे हैं, तो SQL इंजेक्शन हमलों के खिलाफ बचाव करने का सबसे तेज़ और आसान तरीका हमेशा तैयार बयानों का उपयोग करना है। – bakoyaro
आईटी में सब कुछ डाउनसाइड्स है, आपको बस यह जांचने की ज़रूरत है कि क्या वे आपकी विशिष्ट समस्या के बारे में चिंता करने योग्य हैं या नहीं। :) SO http://stackoverflow.com/questions/535464/when-not-to-use-prepared-statements/537834 में यह लिंक तैयार बयानों के नुकसान के बारे में कुछ उदाहरण हैं। – GmonC