एक आवर्ती घटना, परिभाषा के अनुसार, एक ऐसी घटना है जो एक अंतराल पर दोहराई जाती है; इसे एक आवधिक घटना भी कहा जाता है। ऐसे कई एप्लिकेशन हैं जो अपने उपयोगकर्ताओं को पुनरावर्ती ईवेंट सेट करने की अनुमति देते हैं। डेटाबेस सिस्टम आवर्ती घटनाओं का प्रबंधन कैसे करता है? इस लेख में, हम उन्हें संभालने का एक तरीका तलाशेंगे।
अनुप्रयोगों से निपटने के लिए पुनरावृत्ति आसान नहीं है। यह एक तूफानी कार्य बन सकता है, खासकर जब हर संभावित पुनरावर्ती परिदृश्य को कवर करने की बात आती है - जिसमें द्वि-साप्ताहिक या त्रैमासिक ईवेंट बनाना या भविष्य के सभी ईवेंट इंस्टेंस के पुनर्निर्धारण की अनुमति देना शामिल है।
आवर्ती ईवेंट प्रबंधित करने के दो तरीके
मैं डेटा मॉडल में आवधिक कार्यों को संभालने के लिए कम से कम दो तरीकों के बारे में सोच सकता हूं। इससे पहले कि हम उनकी चर्चा करें, आइए इस कार्य की आवश्यकताओं पर शीघ्रता से विचार करें। संक्षेप में, प्रभावी प्रबंधन का अर्थ है:
- उपयोगकर्ताओं को नियमित और पुनरावर्ती ईवेंट बनाने की अनुमति है।
- दैनिक, साप्ताहिक, द्वि-साप्ताहिक, मासिक, त्रैमासिक, द्वि-वार्षिक और वार्षिक कार्यक्रम बिना किसी समाप्ति तिथि प्रतिबंध के बनाए जा सकते हैं।
- उपयोगकर्ता किसी ईवेंट या किसी ईवेंट के भविष्य के सभी इंस्टेंस को फिर से शेड्यूल या रद्द कर सकते हैं।
इन मापदंडों को ध्यान में रखते हुए, डेटा मॉडल में आवर्ती घटनाओं को प्रबंधित करने के दो तरीके दिमाग में आते हैं। हम उन्हें भोला और विशेषज्ञ तरीका कहेंगे।
बेवकूफ रास्ता: किसी ईवेंट के सभी संभावित पुनरावर्ती उदाहरणों को तालिका में अलग-अलग पंक्तियों के रूप में संग्रहीत करना। इस समाधान में, हमें केवल एक तालिका की आवश्यकता है, जिसका नाम है event . इस तालिका में event_title . जैसे कॉलम हैं , start_date , end_date , is_full_day_event , आदि। start_date और end_date कॉलम टाइमस्टैम्प डेटा प्रकार हैं; इस तरह वे उन घटनाओं को समायोजित कर सकते हैं जो पूरे दिन नहीं चलती हैं।
पेशेवर: यह काफी सीधा तरीका है और इसे लागू करना सबसे आसान है।
विपक्ष: भोलेपन के कुछ महत्वपूर्ण नुकसान हैं, जिनमें शामिल हैं:
- किसी घटना के सभी संभावित उदाहरणों को संग्रहीत करने की आवश्यकता। यदि आप एक बड़े उपयोगकर्ता आधार की जरूरतों को ध्यान में रखते हैं तो एक बड़े स्थान की आवश्यकता होती है। हालांकि, जगह काफी सस्ती है, इसलिए इस बिंदु का कोई बड़ा प्रभाव नहीं है।
- एक बहुत ही गड़बड़ अद्यतन प्रक्रिया। मान लीजिए कि किसी घटना को पुनर्निर्धारित किया गया है। उस स्थिति में, किसी को इसके सभी उदाहरणों को अपडेट करना होगा। पुनर्निर्धारण करते समय बड़ी संख्या में DML संचालन करने की आवश्यकता होती है, जो अनुप्रयोग प्रदर्शन पर नकारात्मक प्रभाव डालता है।
- अपवादों को संभालना। सभी अपवादों को इनायत से संभाला जाना चाहिए, खासकर यदि आपको वापस जाना है और अपवाद बनाने के बाद मूल नियुक्ति को संपादित करना है। उदाहरण के लिए, मान लें कि आप किसी पुनरावर्ती ईवेंट की तीसरी आवृत्ति को एक दिन आगे बढ़ाते हैं। क्या होगा यदि आप बाद में मूल घटना के समय को संपादित करते हैं? क्या आप मूल दिन पर एक और घटना दोबारा सम्मिलित करते हैं और जिसे आप आगे लाए थे उसे छोड़ देते हैं? अपवाद अनलिंक करें? इसे उचित रूप से बदलने का प्रयास करें?
Event_id– यह कॉलमeventतालिका, और यह इस तालिका में प्राथमिक कुंजी के रूप में कार्य करता है। यहeventऔरrecurring_patternटेबल। यह कॉलम यह भी सुनिश्चित करेगा कि प्रत्येक घटना के लिए अधिकतम एक आवर्ती पैटर्न मौजूद है।Recurring_type_id- यह कॉलम पुनरावृत्ति के प्रकार को दर्शाता है, चाहे वह दैनिक, साप्ताहिक, मासिक या वार्षिक हो।Max_num_of_occurrances- ऐसे समय होते हैं जब हमें किसी घटना की सही समाप्ति तिथि नहीं पता होती है लेकिन हम जानते हैं कि इसे पूरा करने के लिए कितनी घटनाओं (बैठकों) की आवश्यकता होती है। यह कॉलम एक मनमाना संख्या संग्रहीत करता है जो किसी घटना के तार्किक अंत को परिभाषित करता है।Separation_count- आप सोच रहे होंगे कि कैसे एक द्वि-साप्ताहिक या द्वि-वार्षिक ईवेंट को कॉन्फ़िगर किया जा सकता है यदि केवल चार संभावित पुनरावृत्ति-प्रकार मान (दैनिक, साप्ताहिक, मासिक, वार्षिक) हैं। इसका उत्तर हैseparation_countकॉलम। यह कॉलम अगले ईवेंट इंस्टेंस की अनुमति से पहले अंतराल (दिनों, हफ्तों या महीनों में) को दर्शाता है। उदाहरण के लिए, यदि किसी ईवेंट को हर दूसरे सप्ताह कॉन्फ़िगर करने की आवश्यकता है, तो separation_count =“1” इस आवश्यकता को पूरा करने के लिए। इस कॉलम के लिए डिफ़ॉल्ट मान "0" है।recurring_type_id"साप्ताहिक" होगा।separation_count"1" होगा।- द
day_of_week"2" होगा। Week_of_month- यह कॉलम उन घटनाओं के लिए है जो महीने के एक निश्चित सप्ताह के लिए निर्धारित हैं - यानी पहला, दूसरा, आखिरी, दूसरा से आखिरी, आदि। हम इन मानों को 1,2,3, 4, .. के रूप में संग्रहीत कर सकते हैं। (से गिनती महीने की शुरुआत) या -1,-2,-3,... (माह के अंत से गिनती)।Day_of_month- ऐसे मामले होते हैं जब कोई घटना महीने के किसी विशेष दिन, 25 तारीख को निर्धारित की जाती है। यह कॉलम इस आवश्यकता को पूरा करता है। जैसेweek_of_month, इसे धनात्मक संख्याओं (महीने की शुरुआत से सातवें दिन के लिए "7") या ऋणात्मक संख्याओं (महीने के अंत से सातवें दिन के लिए "-7") से भरा जा सकता है।recurring_type_id"मासिक" होगा।separation_count"2" होगा।- द
day_of_month"11" होगा। - शेष सभी कॉलम रिक्त होंगे।
- छुट्टियों के दिन होने वाले कार्यक्रम। जब किसी घटना का कोई विशेष उदाहरण सार्वजनिक अवकाश पर होता है, तो क्या इसे अवकाश के तुरंत बाद कार्य दिवस में स्वचालित रूप से स्थानांतरित कर दिया जाना चाहिए? या इसे स्वचालित रूप से रद्द कर दिया जाना चाहिए? इनमें से कोई भी किन परिस्थितियों में लागू होगा?
- घटनाओं के बीच संघर्ष। क्या होगा यदि कुछ घटनाएं (जो परस्पर अनन्य हैं) एक ही दिन आती हैं?
विशेषज्ञ तरीका: एक पुनरावर्ती पैटर्न को संग्रहित करना और प्रोग्रामेटिक रूप से अतीत और भविष्य के ईवेंट इंस्टेंस उत्पन्न करना। यह समाधान भोले समाधान के डाउनसाइड्स को संबोधित करता है। हम इस लेख में विशेषज्ञ समाधान के बारे में विस्तार से बताएंगे।
प्रस्तावित मॉडल
ईवेंट बनाना
सभी शेड्यूल किए गए इवेंट, चाहे उनकी नियमित या उनकी आवर्ती प्रकृति कुछ भी हो, event टेबल। सभी ईवेंट पुनरावर्ती ईवेंट नहीं होते हैं, इसलिए हमें फ़्लैग कॉलम की आवश्यकता होगी, is_recurring , इस तालिका में आवर्ती घटनाओं को स्पष्ट रूप से निर्दिष्ट करने के लिए। event_title और event_description कॉलम विषय और घटनाओं का एक संक्षिप्त सारांश संग्रहीत करते हैं। घटना विवरण वैकल्पिक हैं, यही कारण है कि यह कॉलम अशक्त है।
जैसा कि उनके नाम से पता चलता है, start_date और end_date कॉलम घटनाओं की शुरुआत और समाप्ति तिथियां रखते हैं। नियमित घटनाओं के मामले में, ये कॉलम वास्तविक प्रारंभ और समाप्ति तिथियों को संग्रहीत करते हैं। हालांकि, वे आवधिक घटनाओं की पहली और आखिरी घटनाओं की तारीखों को भी संग्रहीत करते हैं। हम end_date रखेंगे कॉलम को अशक्त के रूप में, क्योंकि उपयोगकर्ता बिना किसी समाप्ति तिथि के आवर्ती घटनाओं को कॉन्फ़िगर कर सकते हैं। इस मामले में, एक काल्पनिक समाप्ति तिथि (जैसे एक वर्ष के लिए) तक की भविष्य की घटनाएं UI में दिखाई जाएंगी।
is_full_date_event कॉलम इंगित करता है कि कोई ईवेंट पूरे दिन का ईवेंट है या नहीं। पूरे दिन की घटना के मामले में, start_time और end_time कॉलम शून्य होंगे; यही कारण है कि इन दोनों स्तंभों को अशक्त रखने का कारण है।
created_by और created_date कॉलम स्टोर करते हैं कि किस उपयोगकर्ता ने एक ईवेंट बनाया और उस ईवेंट के बनने की तिथि।
इसके बाद parent_event_id है कॉलम। यह हमारे डेटा मॉडल में एक प्रमुख भूमिका निभाता है। इसका महत्व मैं बाद में बताऊंगा।
पुनरावृत्ति प्रबंधित करना
अब हम सीधे मुख्य समस्या कथन पर आते हैं:क्या होगा यदि event तालिका - यानी is_recurring घटना के लिए ध्वज "Y" है?
जैसा कि पहले बताया गया है, हम घटनाओं के लिए एक आवर्ती पैटर्न संग्रहीत करेंगे ताकि हम इसकी सभी भविष्य की घटनाओं का निर्माण कर सकें। आइए recurring_pattern टेबल। इस तालिका में निम्नलिखित कॉलम हैं:
आइए विभिन्न प्रकार की पुनरावृत्तियों के संदर्भ में शेष स्तंभों के महत्व पर विचार करें।
दैनिक पुनरावृत्ति
क्या हमें वास्तव में एक दैनिक आवर्ती घटना के लिए एक पैटर्न पर कब्जा करने की ज़रूरत है? नहीं, क्योंकि एक दैनिक पुनरावृत्ति पैटर्न उत्पन्न करने के लिए आवश्यक सभी विवरण पहले से ही event टेबल।
एकमात्र परिदृश्य जिसके लिए एक पैटर्न की आवश्यकता होती है, जब ईवेंट वैकल्पिक दिनों या प्रत्येक X दिनों की संख्या के लिए निर्धारित किए जाते हैं। इस मामले में, separation_count कॉलम हमें पुनरावृत्ति पैटर्न को समझने और आगे के उदाहरण प्राप्त करने में मदद करेगा।
साप्ताहिक पुनरावृत्ति
हमें केवल एक अतिरिक्त कॉलम की आवश्यकता है, day_of_week , स्टोर करने के लिए सप्ताह के किस दिन यह ईवेंट होगा। मान लें कि सोमवार सप्ताह का पहला दिन है और रविवार अंतिम है, तो संभावित मान 1,2,3,4,5,6, और 7 होंगे। कोड में उपयुक्त परिवर्तन जो व्यक्तिगत घटना घटनाओं को उत्पन्न करता है, आवश्यकतानुसार किया जाना चाहिए। साप्ताहिक ईवेंट के लिए शेष सभी कॉलम खाली रहेंगे।
आइए एक क्लासिक प्रकार का साप्ताहिक कार्यक्रम लें:द्वि-साप्ताहिक घटना। इस मामले में, हम कहेंगे कि यह हर दूसरे सप्ताह मंगलवार को, सप्ताह के दूसरे दिन होता है। तो:
मासिक पुनरावृत्ति
इसके अलावा day_of_week , हमें किसी भी मासिक पुनरावृत्ति परिदृश्य को पूरा करने के लिए दो और स्तंभों की आवश्यकता है। संक्षेप में, ये कॉलम हैं:
आइए अब एक अधिक जटिल उदाहरण पर विचार करें - एक त्रैमासिक घटना। मान लीजिए कि कोई कंपनी प्रत्येक तिमाही (आमतौर पर जनवरी, अप्रैल, जुलाई और अक्टूबर) में पहले महीने के 11 दिन के लिए तिमाही परिणाम प्रक्षेपण कार्यक्रम निर्धारित करती है। तो इस मामले में:
उपरोक्त उदाहरण में, हम मानते हैं कि उपयोगकर्ता जनवरी में तिमाही परिणाम प्रक्षेपण बना रहा है। कृपया ध्यान दें कि इस अलगाव तर्क की गिनती उस महीने, सप्ताह या दिन से शुरू हो जाएगी जब ईवेंट बनाया जाएगा।
इसी तरह, अर्ध-वार्षिक ईवेंट को
वार्षिक पुनरावृत्ति काफी सीधी है। हमारे पास सप्ताह और महीने के विशेष दिनों के लिए कॉलम हैं, इसलिए हमें वर्ष के महीने के लिए केवल एक अतिरिक्त कॉलम की आवश्यकता है। हमने इस कॉलम का नाम
आइए अब अपवादों पर आते हैं। क्या होगा यदि एक आवर्ती घटना का एक विशेष उदाहरण रद्द या पुनर्निर्धारित किया जाता है? ऐसे सभी उदाहरण
आइए दो स्तंभों पर एक नज़र डालें,
इन दो स्तंभों के अलावा, सभी शेष स्तंभ
ऐसे एप्लिकेशन हैं जो उपयोगकर्ताओं को एक आवर्ती घटना के भविष्य के सभी उदाहरणों को फिर से निर्धारित करने की अनुमति देते हैं। ऐसे में हमारे पास दो विकल्प हैं। हम भविष्य के सभी उदाहरणों को
इस समाधान के साथ, हम किसी घटना की सभी पिछली घटनाओं को प्राप्त कर सकते हैं, भले ही उसके पुनरावृत्ति पैटर्न को बदल दिया गया हो।
आवर्ती घटनाओं के आसपास कुछ और जटिल क्षेत्र हैं जिन पर हमने चर्चा नहीं की है। यहाँ दो हैं:
इन क्षमताओं के निर्माण के लिए हमें क्या परिवर्तन करने की आवश्यकता है? कृपया हमें अपने विचार कमेंट सेक्शन में बताएं।separation_count के साथ मासिक ईवेंट के रूप में लॉग किया जा सकता है "5" का।
वार्षिक पुनरावृत्ति
month_of_year . रखा है ।
आवर्ती घटनाओं के अपवादों को संभालना
event_instance_exception टेबल। Is_rescheduled और is_cancelled . ये कॉलम इंगित करते हैं कि क्या यह उदाहरण किसी बाद की तारीख/समय पर पुनर्निर्धारित किया गया है या पूरी तरह से रद्द कर दिया गया है। इसके लिए मेरे पास दो अलग-अलग कॉलम क्यों हैं? ठीक है, केवल उन घटनाओं के बारे में सोचें जिन्हें पहले पुनर्निर्धारित किया गया था और बाद में पूरी तरह से रद्द कर दिया गया था। ऐसा होता है, और हमारे पास इन स्तंभों के साथ इसे रिकॉर्ड करने का एक तरीका है। event टेबल।
दो ईवेंट को
parent_event_id के माध्यम से क्यों लिंक करें ?event_instance_exception . में स्टोर कर सकते हैं (संकेत:स्वीकार्य समाधान नहीं)। या हम event तालिका बनाएं और इसे id_parent_event के माध्यम से इसके पहले वाले ईवेंट (पैरेंट इवेंट) से लिंक करें कॉलम। आवर्ती ईवेंट हैंडलिंग को कैसे सुधारें?
