क्या मुझे कैलेंडर ऐप बनाने के दौरान अपने डेटाबेस में दिनांक या पुनरावृत्ति नियमों को संग्रहीत करना चाहिए?

Question

मैं एक कैलेंडर वेबसाइट का निर्माण कर रहा हूँ (ASP.NET MVC) आवेदन (लगता है दृष्टिकोण के सरल संस्करण) और मैं अभी मैं में वास्तविक तिथियां भंडारण कर रहा हूँ कैलेंडर घटनाओं कि आवर्ती कर रहे हैं (मासिक, वार्षिक, आदि)

समर्थन शुरू करना चाहते हैं मेरे लेकिन मैं यह जानना चाहता था कि, पुनरावृत्ति के साथ, क्या तारीखों को संग्रहीत करना जारी रखना (कुछ स्पष्ट कटऑफ के साथ), या मुझे पुनरावृत्ति विकल्प स्टोर करना चाहिए और फ्लाई पर तिथियां उत्पन्न करना चाहिए।

यह मुझे सोच रहा है कि कैसे दृष्टिकोण, Google मेल इत्यादि यह या किसी अन्य सेवा को आवर्ती कैलेंडर आइटम का समर्थन करता है।

क्या इस पर कोई सुझाव हैं?

Answer 1

अपने डेटा को दो हिस्सों में अलग करें: "कैनोलिक" डेटा (पुनरावृत्ति नियम) और "सेवारत" (जेनरेट की तारीखें; पुनर्जन्म से केवल पढ़ने के लिए)। यदि कैनोलिक डेटा बदलता है, तो उस बिंदु पर "सेवारत" डेटा को पुन: उत्पन्न करें। अनंत पुनरावृत्ति के लिए, यदि आप बाहर निकलते हैं तो कुछ उदाहरण रखें और अधिक उत्पन्न करें (उदा। यदि उपयोगकर्ता 2020 के लिए अपना कैलेंडर देखता है)।

यदि आप अनंत प्रोसेसर गति थी, आप केवल विहित डेटा आवश्यकता होगी - लेकिन वास्तविकता में, सभी पुनरावृत्ति नियम पर हर पृष्ठ दृश्य भी समय लेने वाली हो जाने की संभावना है के लिए सभी दिनांक/समय प्रसंस्करण कर रही है ... ताकि आप दोहराए गए गणना को बचाने के लिए कुछ भंडारण (और जटिलता) का व्यापार कर सकें। बड़ी संख्या में घटनाओं के लिए आवश्यक गणना के मुकाबले भंडारण आमतौर पर बहुत सस्ता होता है। यदि आप केवल घटनाओं की तिथियों को संग्रहीत करने की आवश्यकता है, तो यह वास्तव में बहुत सस्ता है - आप आसानी से एक तिथि का प्रतिनिधित्व करने के लिए 4 बाइट पूर्णांक का उपयोग कर सकते हैं, और उसके बाद से एक पूर्ण तिथि/समय उत्पन्न कर सकते हैं, मानते हैं कि आपकी आवर्ती सभी दिनांक आधारित हैं । समय-आधारित पुनरावृत्ति (उदाहरण के लिए "हर तीन घंटे") के लिए आप पूर्ण यूटीसी इंस्टेंट्स को पूरा कर सकते हैं - 8 बाइट्स उस समय तक एक सुंदर ठीक रिज़ॉल्यूशन तक प्रतिनिधित्व करेंगे जब तक आपको इसकी आवश्यकता हो।

आप हालांकि वैधता बनाए रखने के बारे में सावधान होने की जरूरत है - एक आवर्ती बैठक को परिवर्तित करता है आज, कि परिवर्तन नहीं करता है यह जब अतीत में क्या हुआ है ... तो आप शायद करना चाहते भी विहित है वास्तव में जब पुनरावृत्ति वास्तव में हुआ था के बारे में केवल पढ़ने के लिए डेटा। जाहिर है, आप नहीं चाहते हैं कि अतीत को हमेशा के लिए रखें, इसलिए आप शायद अपनी स्टोरेज सीमाओं के आधार पर कुछ साल से अधिक "कचरा इकट्ठा" करना चाहते हैं।

आपको प्रति-घटना के आधार पर नोट्स और अपवाद जोड़ने की क्षमता भी हो सकती है (उदाहरण के लिए "सार्वजनिक अवकाश के कारण आज बैठक नहीं होती है" या "4:00 बजे स्थानांतरित हो जाती है")। यह वास्तव में मजेदार हो जाता है जब आप पुनरावृत्ति बदलते हैं - यदि आप "हर सोमवार" को "हर मंगलवार" में बदलते हैं तो क्या आप अपवाद रखते हैं या नहीं? जब आप "हर दिन" से "हर सप्ताह" में बदलते हैं तो आप अपवादों का मिलान कैसे करते हैं? ये ऐसे प्रश्न नहीं हैं जो सीधे भंडारण के बारे में हैं - लेकिन भंडारण निर्णय इस बात को प्रभावित करेंगे कि आप जिस नीति पर निर्णय लेते हैं उसे लागू करना कितना आसान है।

Answer 2

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

यहां आपके प्रश्न की तारीफ करने का एक अच्छा जवाब है।
Data structure for storing recurring events?

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

Answer 3

मुझे कुछ साल पहले किए गए वेब-एप्लिकेशन में एक ही समस्या थी (अब बेहतर तरीका हो सकता है :))। मैं एक शेड्यूलर शामिल करना चाहता था जिसमें पुनरावर्ती घटनाओं की सभी कार्यक्षमताएं थीं, समय, दिन, सप्ताह, महीनों, वर्षों और अपवादों को संभालने के लिए, ताकि मेरे पास नियम हो सकें:

1) प्रत्येक दिन 10 बजे छोड़कर बुधवार

2) प्रतिदिन

3) 4 पुनरावृत्तियों की एक अधिकतम महीना

आदि के प्रत्येक पहले सोमवार के साथ हर 2 घंटे ..

आवर्ती दिनांकों भंडारण/बार संभव हो गया था, लेकिन अनम्य । जब आपका "अधिकतम" होगा तो आपके ईवेंट का प्रत्येक पुनरावृत्ति बदल जाएगा। और आप कितनी दूर दिखते हैं?

अंत में मैंने एक कस्टम शेड्यूलिंग क्लास लिखा जो एक स्ट्रिंग से पढ़ और लिख सकता था। यह स्ट्रिंग था जो डेटाबेस में संग्रहीत थी और फिर अगली घटना होने पर पता लगाने के लिए एक साधारण फ़ंक्शन कहा जा सकता है।

Answer 4

मुझे एक ऐसी प्रणाली बनाना पड़ा जो शेड्यूलिंग के साथ काम करता था और हमने दोनों किया था। यहां हमारे पास

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

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

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

Answer 5

आपको उनमें से कुछ को निश्चित रूप से स्टोर करने की आवश्यकता है। उपयोगकर्ता किसी भी घटना को संपादित कर सकता है, जिससे दूसरों को छेड़छाड़ नहीं मिलती है (आप शायद इस सवाल से मिले: "क्या आप कुछ आवर्ती घटनाओं को संपादित करना चाहते हैं या केवल यह एक?" कुछ कैलेंडर में, यानी विंडोज मोबाइल)।

आप पिछली घटनाओं को स्टोर करना चाहेंगे और जब उपयोगकर्ता पुनरावर्ती घटना को हटा देता है तो उन्हें हटा नहीं सकता है।

यदि आप अन्य सभी को स्टोर करते हैं या उन्हें उत्पन्न करते हैं तो एक कार्यान्वयन विवरण होता है। यदि संभव हो तो मैं उन्हें उत्पन्न करना पसंद करूंगा।

किसी भी मामले में आप प्रत्येक घटना के साथ आवर्ती आवर्ती ईवेंट की कुछ आईडी चाहते हैं, साथ ही कुछ ध्वज आपको बताएंगे कि ईवेंट बाद में संशोधित किया गया था या नहीं। या अधिक जटिल दृष्टिकोण में, प्रत्येक ईवेंट प्रॉपर्टी के लिए एक ध्वज बताता है, यदि यह डिफ़ॉल्ट मान (पुनरावर्ती घटना से) या यदि यह इस विशेष उदाहरण के लिए संशोधित किया गया था। जब उपयोगकर्ता पुनरावर्ती ईवेंट को संपादित करने का निर्णय लेता है तो आपको इसकी आवश्यकता होगी।

Answer 6

आपको अलग-अलग घटनाओं और घटनाओं को संभालने की आवश्यकता होगी।

घटना वार: घटनाओं के लिए, आप पुनरावर्तन नियमों लेकिन यह भी अपवाद (rfc5545 द्वारा निर्दिष्ट लेकिन यह भी rfc5545 में rdate तरह तिथियों की एक स्पष्ट सेट की तरह है जो एक rrule हो सकता है) की दुकान करने की आवश्यकता होगी (rfc5545 और संभवतः के exdate देखना rfc2445 में exrule)। आपको उन नियमों में परिवर्तनों का ट्रैक रखने की भी आवश्यकता होगी: राडेट में परिवर्तन, भविष्य में होने पर पुरानी कोई समस्या नहीं है और पिछली तिथियों के लिए अनदेखा किया जाना चाहिए। पिछले अवसरों को प्रभावित करने के रूप में क्रुले में परिवर्तन अधिक कठिन हैं। मेरी व्यक्तिगत वरीयता है कि वे अपनी संबंधित शुरुआत और वैधता की समाप्ति तिथि निर्दिष्ट करने के लिए पुराने और नए क्रॉल के लिए एक विशिष्ट संपत्ति जोड़ना चाहते हैं।

यदि ईवेंट में सीमित समय अवधि है (COUNT या यूएनटीआईएल संपत्ति मौजूद है) तो आपको ईवेंट की आसान पूछताछ की अनुमति देने के लिए अपनी तालिका में अपनी शुरुआत और अंत स्टोर करना चाहिए (विशेष रूप से जब आपकी पूर्व निर्धारित समय खिड़की के बाहर होने वाली घटनाओं की तलाश होती है (देखें नीचे), यह उन घटनाओं की संख्या को कम करने में मदद कर सकता है जिनके लिए गणना को फिर से किया जाना है)।

घटनाओं वार: आवृत्तियां के लिए आप एक पूर्वनिर्धारित खिड़की के आसपास मौजूद भीतर उदाहरणों संग्रहीत करना चाहिए (माना +/- 6 महीने या 12months और एक नियमित आधार पर गणना की) और अपने उपयोगकर्ताओं को चाहते हैं, तो फिर से गणना की अनुमति देने के लिए इस का रिकॉर्ड रखने के भविष्य में आगे देखने के लिए (प्रदर्शन के मुद्दों के लिए)। आपको अगली घटना की आसान खोज में मदद के लिए इंडेक्स (रिक्रेंस-आईडी) की गणना करने पर भी विचार करना चाहिए।

बैक एंड पर कम लेकिन फ्रंट-एंड पर अधिक आपको उपयोगकर्ता से पूछने के लिए tzid परिवर्तनों का ट्रैक रखना चाहिए यदि किसी ईवेंट को किसी दिए गए tzid पर निर्धारित किया गया हो, तो यह वर्तमान समय क्षेत्र पर रहने के लिए है इसे अद्यतन करने की जरूरत है (समोआ द्वीप में किसी के बारे में सोचें, जिसने शुक्रवार को 30 दिसंबर 2011 को एक बैठक निर्धारित की थी, देश ने तय किया था कि यह दिन मौजूद नहीं होगा), इसी तरह आप पूछ सकते हैं कि डेलाइट सेविंग टाइम के दौरान होने वाली कोई घटना क्या है आप क्या पुनरावर्तन नियमों के संदर्भ में rfc5545 में परिभाषित किया गया है परे समर्थन पर विचार करने और भी धार्मिक आवर्ती नियमों के लिए समर्थन जोड़ने के लिए चाहते हो सकता है: "कभी नहीं" या "दो बार होता है"

नोट (इस विषय here पर और अधिक) के लिए होती (see USNO introduction to calendars या प्रिंट में "कैलेंड्रल कैलकुलेशन" (तीसरा संस्करण) ई। रींगोल और एन। डर्सोविट्ज़)।

जब से तुम मौजूदा कार्यान्वयन के बारे में पूछते हैं, आप आसानी से सनबर्ड (SQLite) के डेटाबेस स्कीमा जांच कर सकते हैं या Apple open source Calendar and Contacts Server की, CalDAV सर्वर के लिए मौजूदा खुला स्रोत परियोजनाओं की एक और पूरी सूची (जो शायद आप क्या कर रहे हैं के एक सबसेट है खोज रहे हैं) here उपलब्ध है)