टाइमर-आधारित घटना ट्रिगर्स

मैं वर्तमान में विशिष्ट आवश्यकताओं के साथ एक परियोजना पर काम कर रहा हूं। इनके बारे में एक संक्षिप्त अवलोकन निम्नानुसार है:

  • बाहरी वेबसाइसेस से डेटा पुनर्प्राप्त किया जाता है
  • डेटा SQL 2005 में संग्रहीत है
  • डेटा को एक वेब GUI
  • के माध्यम से छेड़छाड़ की जाती है
  • विंडोज सेवा के साथ संचार करने वाली विंडोज सेवा डेटाबेस के माध्यम से, हमारे आंतरिक वेब यूआई के साथ कोई युग्मन नहीं है।
  • वेब सेवाओं के साथ संचार समय-आधारित दोनों होना चाहिए, और वेब यूआई पर उपयोगकर्ता हस्तक्षेप के माध्यम से ट्रिगर किया जाना चाहिए।

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

1) Adapt the trigger table to store two extra parameters. One being "Is this time-based or manually added?" and a nullable field to store the timing details (exact format to be determined). If it is a manaully created trigger, mark it as processed when the trigger has been fired, but not if it is a timed trigger.
or
2) Create a second windows service that creates the triggers on-the-fly at timed intervals.

दूसरा विकल्प मेरे लिए एक झुकाव जैसा प्रतीत होता है, लेकिन विकल्प 1 का प्रबंधन आसानी से एक प्रोग्रामिंग दुःस्वप्न में बदल सकता है (आप कैसे जानते हैं कि तालिका के आखिरी मतदान में आग लगने की आवश्यकता है, और फिर आप इसे कैसे रोकते हैं अगले चुनाव पर फिर से ट्रिगरिंग)

मैं इस बात की सराहना करता हूं कि अगर कोई मुझे यह तय करने में मदद करने के लिए कुछ मिनट दे सकता है कि कौन सा मार्ग (इन दोनों में से एक, या संभवतः एक तिहाई, असूचीबद्ध एक) लेना है।

0
जोड़ा संपादित
विचारों: 1

3 उत्तर

जिस तरह से मैं इसे देखता हूं यह है।

आपके पास एक विंडोज सेवा है, जो शेड्यूलर की भूमिका निभा रही है और इसमें कुछ कक्षाएं हैं जो वेबसर्विसेज को कॉल करती हैं और डेटा को आपके डेटाबेस में रखती हैं।

इसलिए, आप इन वर्गों का सीधे वेबयूआई से भी उपयोग कर सकते हैं और वेबयूआई ट्रिगर के आधार पर डेटा आयात कर सकते हैं।

मुझे डेटाबेस में ध्वज (ट्रिगर) के रूप में उपयोगकर्ता द्वारा उत्पन्न क्रिया को संग्रहीत करने का विचार पसंद नहीं है, जहां कुछ सेवा उस क्रिया को निष्पादित करने के लिए इसे (अंतराल पर जो उपयोगकर्ता के नियंत्रण में नहीं है) को मतदान करेगी।

आप पूरे कोड को एक एक्सई में भी परिवर्तित कर सकते हैं जिसे आप विंडोज शेड्यूलर का उपयोग करके शेड्यूल कर सकते हैं। और जब भी उपयोगकर्ता वेब यूआई से कार्रवाई को ट्रिगर करता है तो उसी एक्सई को कॉल करें।

0
जोड़ा

@Vaibhav

दुर्भाग्यवश, समाधान की भौतिक वास्तुकला, वेब UI से डेटाबेस के अलावा, और सेवा के लिए डेटाबेस (जो तब वेब सेवाओं पर कॉल कर सकती है) के अलावा घटकों के बीच किसी भी प्रत्यक्ष संचार की अनुमति नहीं देगी। हालांकि, मैं सहमत हूं कि संचार कक्षाओं का पुन: उपयोग यहां आदर्श होगा - मैं इसे अपने व्यापार की सीमाओं के भीतर नहीं कर सकता *

* क्या यह हमेशा ऐसा नहीं होता है कि तकनीकी रूप से "बेहतर" समाधान बाह्य कारकों से घिरा हुआ हो?

0
जोड़ा

Windows सेवा के बजाय SQL कार्य का उपयोग क्यों न करें? आप संग्रहीत प्रक्रियाओं में आप सभी डीबी "ट्रिगर" कोड को समाहित कर सकते हैं। फिर आपका यूआई और एसक्यूएल जॉब एक ​​ही संग्रहीत प्रक्रियाओं को कॉल कर सकता है और ट्रिगर्स को उसी तरह बना सकता है चाहे वह मैन्युअल रूप से या एक समय अंतराल पर हो।

0
जोड़ा