दो तालिकाओं के लिए ट्रिगर विकल्प जिन्हें पारस्परिक रूप से एक दूसरे को अद्यतन करना है

यहां ट्रिगर्स का उपयोग करना केवल परेशानी पूछ रहा है।

इसके अलावा, शेड्यूलर का उपयोग करने का विकल्प शायद सबसे अच्छा विचार नहीं है क्योंकि शेड्यूल किए गए कार्य केवल प्रतिबद्ध डेटा देख सकते हैं। तो या तो आप ट्रिगर में काम कर रहे हैं जो खिड़की से लेनदेन तर्क फेंकता है या लेनदेन के अंत तक तालिकाओं में परिवर्तन में देरी हो रही है।

आपको या तो करना चाहिए:

1. प्रक्रियाओं का प्रयोग करें। सबसे सरल उत्तर। जब आपके पास कई एप्लिकेशन हों तो उन्हें सीधे डीएमएल/बिजनेस लॉजिक नहीं करना चाहिए, उन्हें इसे हमेशा प्रक्रियाओं के साथ करना चाहिए ताकि वे सभी एक ही कोड चला सकें। प्रत्यक्ष डीएमएल को अनुदान या विचारों के साथ मना करें। आपको INSTEAD OF . के माध्यम से प्रक्रियाओं के उपयोग को बाध्य करने की आवश्यकता हो सकती है विचारों पर ट्रिगर (इस पर तभी विचार करें जब आप एप्लिकेशन को संशोधित नहीं कर सकते)।

2. शायद आपके मामले में प्रक्रियाओं से भी बेहतर:एक स्कीमा का उपयोग करें जिसमें डुप्लिकेट डेटा न हो। आप अनावश्यक डेटा संग्रहीत नहीं करना चाहते हैं:यह अनुप्रयोग विकास को आवश्यकता से अधिक जटिल बनाता है। प्रदर्शन, संसाधनों और ऊर्जा के संदर्भ में, किसी समस्या को हल करने का सबसे अच्छा तरीका तब होता है जब आपको पता चलता है कि कार्य अनावश्यक है।

   आपके मॉडल के विवरण से, यहां वे स्तंभ दिए गए हैं जिन्हें आप निकाल सकते हैं:

   • task.duration_in_days
   • task.end_date
   • task.needs_recomputation
   • उपकार्य.प्रारंभ_दिनांक
   • subtask.end_date

   
   task तालिका में केवल प्रारंभ तिथि होगी, और प्रत्येक उप-कार्य केवल इसकी अवधि संग्रहीत करेगा। जब आपको समग्र जानकारी की आवश्यकता हो, तो जॉइन का उपयोग करें। आप एप्लिकेशन को डेटा को पारदर्शी रूप से एक्सेस करने देने के लिए दृश्यों का उपयोग कर सकते हैं।

3. एक उत्परिवर्तित ट्रिगर वर्कअराउंड का उपयोग करें जो BEFORE . के साथ संशोधित पंक्तियों की पहचान करने के लिए पैकेज चर का उपयोग करता है और AFTER बयान ट्रिगर। जाहिर है इसमें बहुत सारे कोड शामिल होंगे जिन्हें कोड करना, परीक्षण करना और बनाए रखना मुश्किल होगा, इसलिए आपको इसके बजाय विकल्प (1) और (2) का उपयोग करना चाहिए।