संग्रहीत दिनचर्या और ट्रिगर पर प्रतिबंध के अनुसार , गतिशील sql का उपयोग नहीं किया जा सकता है (संस्करण 5.0.13 और बाद के संस्करण में संग्रहीत प्रक्रियाओं के लिए उठाया गया प्रतिबंध)। यह सीमा क्यों है? और इसे प्रक्रियाओं के लिए क्यों उठाएं, लेकिन फ़ंक्शन या ट्रिगर नहीं?
जवाबों:
प्रश्न को सुनने से मुझे दो पहलुओं के बारे में सोचना पड़ता है:
ASPECT # 1: कार्यों को अनुमानित माना जाता है
यदि ऐसा है, तो इसका मतलब यह है कि किसी फ़ंक्शन को दिए गए सेट पैरामीटर के लिए लगातार एक ही रिटर्न डेटा पेश करना चाहिए, NO MATTER WHEN YOU CALL THE FUNCTION।
अब, एक फ़ंक्शन की कल्पना करें जो फ़ंक्शन में स्टेटिक एसक्यूएल के आधार पर दिन के अलग-अलग समय पर डेटा इकट्ठा करने के कारण एक अलग उत्तर का उत्पादन करता है। एक मायने में, अगर आप हर बार तालिकाओं और स्तंभों के एक ही सेट को क्वेरी करते हैं, तो इसे अभी भी डीटेरेमिनिस्टिक माना जा सकता है।
क्या होगा यदि आप डायनामिक एसक्यूएल के माध्यम से किसी फ़ंक्शन की अंतर्निहित तालिकाओं को बदल सकते हैं? आप एक डीटेलियम फ़ंक्शन की परिभाषा का उल्लंघन कर रहे हैं।
ध्यान दें कि MySQL ने इस विकल्प को /etc/my.cnf में जोड़ा है
log-bin-trust-function-creatorsहालांकि यह कहने के लिए एक निरीक्षण हो सकता है, लेकिन यह फ़ंक्शन को बाइनरी लॉग में डेटा लिखने की अनुमति दी जा सकती है ताकि डीटेरिमिनिस्टिक संपत्ति को कड़ाई से लागू किया जा सके।
ASPECT # 2: ट्रिगर को वापस रोल करने में सक्षम होना चाहिए
आपके पास अनिवार्य रूप से डेटा होगा जो केवल MVCC में चतुर्भुज (यहां तक कि तेजी से) बढ़ता है। ट्रिगर्स के साथ एसक्यूएल के रोलबैक के प्रबंधन की प्रक्रिया जो गैर-डीटामिनिस्टिक हो सकती है, कम से कम कहने के लिए, जटिल रूप से जटिल होगी।
इन दो पहलुओं के प्रकाश में, मुझे यकीन है कि MySQL डेवलपर्स ने इन चीजों के बारे में सोचा था और प्रतिबंधों को लागू करके उन्हें जल्दी से खारिज कर दिया था।
तो, प्रक्रियाओं के लिए प्रतिबंध क्यों उठाएं? सीधे शब्दों में कहें, तो DETERMINISTIC गुणों या रोलबैक पर कोई चिंता नहीं है।
यह एक महान प्रश्न है, लेकिन मुझे इसका उत्तर नहीं पता है। मुझे लगता है कि यह आंतरिक टीम के लिए किया जा रहा है, लेकिन मैं नहीं जानता कि वे इस साइट में बड़ा हो जाएगा। इस बीच, मैं आपको कुछ उत्तरों को घटाने में मदद कर सकता हूं।
शुरुआत के लिए मैं इसे देखता हूं:
ट्रिगर कैश का पता नहीं चलता है कि अंतर्निहित वस्तुओं का मेटाडेटा कब बदल गया है। यदि ट्रिगर किसी तालिका का उपयोग करता है और ट्रिगर कैश में लोड होने के बाद तालिका बदल गई है, तो ट्रिगर पुराने मेटाडेटा का उपयोग करके संचालित होता है।
जो मुझे लगता है कि इसके साथ कुछ करना है। यदि यह मेटाडेटा की निगरानी भी नहीं कर रहा है, तो यह SQL को फिर से स्थापित करने वाला नहीं है। जिसका मतलब है कि यह एक इंजन की चिंता है।
उसी टोकन के द्वारा, जब मैं इस ब्लॉक को पढ़ता हूं तो मुझे लगता है कि एक ही चीज (इंजन):
सर्वर थ्रेड्स के बीच इंटरैक्शन की समस्याओं को रोकने के लिए, जब कोई क्लाइंट एक स्टेटमेंट जारी करता है, तो सर्वर स्टेटमेंट के लिए उपलब्ध रूटीन और ट्रिगर्स के स्नैपशॉट का उपयोग करता है। यही है, सर्वर प्रक्रियाओं, कार्यों, और ट्रिगर्स की एक सूची की गणना करता है जो कथन के निष्पादन के दौरान उपयोग किए जा सकते हैं, उन्हें लोड करता है, और फिर कथन को निष्पादित करने के लिए आगे बढ़ता है। इसका मतलब यह है कि जब कथन निष्पादित होता है, तो यह अन्य थ्रेड्स द्वारा निष्पादित दिनचर्या में बदलाव नहीं देखेगा।
तो सभी में मैं पूरी तरह से आश्वस्त नहीं हूं कि वे इसकी अनुमति क्यों नहीं देते, लेकिन मैं अनुमान लगा सकता हूं। क्षमा करें कि मैं आपकी अधिक मदद नहीं कर सकता, मैं इसे कुछ और बताने के लिए तैयार हूं। जब हम निजी बीटा छोड़ते हैं, तो कुछ सक्रिय MySQL देवों के लिए आशा करना अच्छा है;)
बड़े पैमाने पर, यह सुरक्षा के कारण है। प्रक्रियाओं का अपवाद इसलिए है क्योंकि प्रक्रिया के भीतर गतिशील एसक्यूएल को निष्पादित उपयोगकर्ता का सुरक्षा संदर्भ सौंपा जा सकता है। इसका मतलब यह है कि भले ही इंजन को पता नहीं है कि क्या निष्पादित होने जा रहा है, यह सुनिश्चित कर सकता है कि उपयोगकर्ता को संदर्भित ऑब्जेक्ट (नों) तक पहुंचने की अनुमति है।
इसके अलावा, आप क्या हो सकता है के बदसूरत मुद्दों को उठा सकते हैं, क्या यह अनुमेय था।