दिलचस्प समस्या। यह मेरा सबसे अच्छा अनुमान है। मैंने इसका कोई परीक्षण नहीं किया है।
सामान्यतया, पोस्टग्रेज का शिक्षित अनुमान यह बताता है कि डेटा पर कथनों का क्या प्रभाव पड़ेगा, ट्रिगर लॉजिक में विस्तारित नहीं होता है। दूसरा कथन निष्पादित करते समय, पोस्टग्रेज़ विदेशी कुंजी बाधा को देखता है, और जानता है कि उसे यह जांचना है कि क्या मान असाइन किया जा रहा है (सम्मिलित) मान्य है, अर्थात, यदि यह विदेशी तालिका में एक मान्य कुंजी का प्रतिनिधित्व करता है। यह संभव है, हालांकि खराब अभ्यास, ट्रिगर का प्रस्तावित विदेशी कुंजी की वैधता पर प्रभाव पड़ सकता है (उदाहरण के लिए यदि ट्रिगर रिकॉर्ड हटा देता है)।
(केस 1) यदि कोई ट्रिगर नहीं है, तो यह डेटा (दोनों पूर्व-प्रतिबद्ध और प्रतिबद्ध के लिए मंचित) को देख सकता है और तय कर सकता है कि प्रस्तावित मूल्य की गारंटी मान्य है या नहीं। (केस 2) यदि कोई एफके बाधा नहीं है, तो ट्रिगर प्रविष्टि की वैधता को प्रभावित नहीं कर सकता है, इसलिए इसकी अनुमति है। (केस 3) अगर आप detail_id=null . को छोड़ देते हैं , अपडेट में कोई बदलाव नहीं है इसलिए ट्रिगर सक्रिय नहीं होगा, इसलिए इसकी उपस्थिति अप्रासंगिक है।
मैं जब भी संभव हो एफके बाधाओं और ट्रिगर दोनों से बचने की कोशिश करता हूं। मेरी राय में, यह बेहतर है कि डेटाबेस में गलती से आंशिक रूप से गलत डेटा शामिल हो जाए और फिर इसे पूरी तरह से लटका दिया जाए, जैसा कि आप यहां देख रहे हैं। मैं सभी एफके बाधाओं और ट्रिगर्स को छोड़ दूंगा, और सभी अपडेट और सम्मिलित कार्यों को संग्रहीत कार्यों के माध्यम से संचालित करने के लिए मजबूर करूंगा, जो एक स्टार्ट/प्रतिबद्ध लॉक के अंदर सत्यापन करते हैं, और पोस्टग्रेज को मजबूर करने के बजाय गलत/अमान्य डालने/अपडेट प्रयासों को उचित और तुरंत संभालते हैं। आदेश 2 की अनुमति है या नहीं यह तय करने से पहले आदेश 1 के लिए प्रतीक्षा करें।
संपादित करें: देखें यह सवाल
2 संपादित करें: बाधाओं की जांच के सापेक्ष ट्रिगर्स के समय के आसपास आधिकारिक दस्तावेज में मुझे जो सबसे नज़दीकी चीज मिल सकती है वह यह है दस्तावेज़ों को ट्रिगर करता है
यह थोड़ा अस्पष्ट है, अगर बाधा जांच से पहले होने वाला ट्रिगर अन्य लेनदेन की बाधा जांच पर लागू होता है। जो भी हो, यह समस्या या तो एक बग है या खराब दस्तावेज है।
