स्टेटिक बनाम डायनेमिक sql

आपका उदाहरण कोड इतना सरल है कि थोड़ा अंतर होगा, लेकिन उस स्थिति में स्थिर संस्करण बेहतर ढंग से निष्पादित होने की संभावना है।

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

दूसरा कारण यह है कि कभी-कभी पैरामीटर के रूप में बाइंड वैरिएबल का उपयोग करना काउंटर-उत्पादक हो सकता है।

एक उदाहरण यह है कि यदि आपके पास स्थिति फ़ील्ड जैसा कुछ है, जहां डेटा समान रूप से वितरित नहीं है (लेकिन अनुक्रमित है)।

निम्नलिखित 3 कथनों पर विचार करें, जब 95% डेटा 'प्रोसेस्ड' हो

   SELECT col FROM table 
   WHERE status = 'U'-- unprocessed
   AND company = :company

   SELECT col FROM table 
   WHERE status = 'P' -- processed
   AND company = :company

   SELECT col FROM table
   WHERE status = :status
   AND company = :company

अंतिम संस्करण में, Oracle एक सामान्य व्याख्या योजना का चयन करेगा। पहले संस्करण में, यह तय कर सकता है कि स्थिति पर सूचकांक के साथ शुरू करने के लिए सबसे अच्छी योजना है (यह जानते हुए कि 'असंसाधित प्रविष्टियां कुल का एक बहुत छोटा हिस्सा हैं)।

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

नकारात्मक पक्ष

एक ही डायनामिक SQL स्टेटमेंट के प्रत्येक दोहराव में एक सॉफ्ट पार्स होता है, जो एक स्टैटिक स्टेटमेंट की तुलना में एक छोटा ओवरहेड होता है, लेकिन फिर भी एक ओवरहेड होता है।

प्रत्येक नया sql स्टेटमेंट (डायनेमिक या स्टैटिक) SGA (साझा मेमोरी) पर भी लॉक लगाता है, और इसके परिणामस्वरूप 'पुराने' स्टेटमेंट्स को बाहर धकेला जा सकता है।

एक खराब, लेकिन सामान्य, सिस्टम डिज़ाइन किसी के लिए डायनेमिक SQL का उपयोग करने के लिए सरल चयन उत्पन्न करने के लिए है जो केवल कुंजी द्वारा भिन्न होता है - अर्थात

SELECT col FROM table WHERE id = 5
SELECT col FROM table WHERE id = 20
SELECT col FROM table WHERE id = 7

व्यक्तिगत बयान त्वरित होंगे, लेकिन समग्र सिस्टम प्रदर्शन खराब हो जाएगा, क्योंकि यह साझा संसाधनों को मार रहा है।

इसके अलावा - गतिशील एसक्यूएल के साथ संकलन समय पर त्रुटियों को फंसाना कहीं अधिक कठिन है। यदि पीएल/एसक्यूएल का उपयोग कर रहे हैं तो यह एक अच्छा संकलन समय जांच कर रहा है। यहां तक ​​​​कि जेडीबीसी जैसे कुछ का उपयोग करते समय (जहां आप अपने सभी डेटाबेस कोड को स्ट्रिंग्स में ले जाते हैं - अच्छा विचार!) आप जेडीबीसी सामग्री को सत्यापित करने के लिए प्री-पार्सर प्राप्त कर सकते हैं। डायनामिक SQL =केवल रनटाइम परीक्षण।

उपरिव्यय

तत्काल निष्पादन का ओवरहेड छोटा है - यह एक सेकंड के हज़ारवें हिस्से में है - हालाँकि, यह जोड़ सकता है यदि यह एक लूप के अंदर है / एक बार प्रति ऑब्जेक्ट / आदि नामक विधि पर। मुझे एक बार डायनामिक को बदलकर 10x गति में सुधार मिला उत्पन्न स्थिर SQL के साथ SQL। हालांकि, इसने कोड को जटिल बना दिया, और ऐसा केवल इसलिए किया गया क्योंकि हमें गति की आवश्यकता थी।