आप ए पर ट्रिगर को बी पर ट्रिगर को सतर्क करने के लिए कुछ कर सकते हैं कि उसे आग लगाने की आवश्यकता नहीं है। एक सत्र के लिए कुछ राज्य स्थापित करना चाहते हैं। सबसे आसान संभव तरीका कुछ ऐसा करना होगा जैसे बूलियन वैरिएबल bypass_checks_on_b के साथ एक पैकेज बनाना। जिसे आपने TRUE . पर सेट किया है इससे पहले कि आप UPDATE A पर, FALSE पर सेट करें एक बार UPDATE पूर्ण करें, और फिर अपना सत्यापन करने से पहले B पर अपने ट्रिगर में इस चर की स्थिति की जांच करें। आप पैकेज का उपयोग करने के बजाय अस्थायी तालिका या संदर्भ के साथ भी कुछ ऐसा ही कर सकते हैं। कम कुशलता से, आप संभावित रूप से बी पर अपने ट्रिगर के अंदर कॉल स्टैक को पार्स कर सकते हैं यह देखने के लिए कि ए पर ट्रिगर कॉल स्टैक में है या नहीं, लेकिन यह बदसूरत होगा।
हालांकि, मैं इस पूरी वास्तुकला के बारे में बहुत सतर्क रहूंगा। जब आप पाते हैं कि आपके पास ए पर ट्रिगर्स हैं जो बी पर ट्रिगर्स को आग लगाते हैं जो ए से पूछताछ करना चाहते हैं, तो यह लगभग हमेशा ऐसा होता है कि आपने ट्रिगर्स में बहुत अधिक तर्क दिया है और आप बेहतर सेवा प्रदान करेंगे उस तर्क को एक संग्रहीत प्रक्रिया परत में जिसे सीधे सम्मिलित या अद्यतन करने वाले अनुप्रयोगों के बजाय बुलाया जा सकता है। जब आप ट्रिगर्स में बहुत अधिक तर्क को धक्का देते हैं, तो आप एक ऐसी प्रणाली के साथ समाप्त हो जाते हैं जिसे समझना बहुत मुश्किल होता है क्योंकि एप्लिकेशन कोड को देखने से यह स्पष्ट नहीं होता है कि विभिन्न कथनों के किस प्रकार के दुष्प्रभाव हैं। और आप बहुत ही स्टेटफुल कोड के साथ समाप्त होते हैं जहां आपके पास कॉलर के आधार पर कोड के एक टुकड़े के माध्यम से कई पथ होते हैं। इसका लगभग निश्चित रूप से मतलब है कि ऐसे राज्य होंगे जो आप परीक्षण नहीं करते हैं या यह नहीं सोचते हैं कि आप कहां पाएंगे कि आपका कोड कुछ अप्रत्याशित करता है। एक टन राज्य होने और एक टन साइड-इफेक्ट्स के साथ कोड बेस होने के बीच, आप बहुत जल्दी एक कोड बेस बना सकते हैं जो अनिवार्य रूप से अप्राप्य है।
