Google कैलेंडर

Question

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

कठिन हिस्सा फिर से होने वाली घटनाओं से निपटने है, घटनाओं तालिका में पंक्ति एक EVENT_TYPE क्षेत्र है जो आपको बताता घटना किस तरह यह, है एक घटना केवल एक ही तिथि, या एक फिर से घटित के लिए हो सकता है के बाद से है घटना हर एक्स दिन।

मुख्य डिजाइन चुनौती फिर से होने वाली घटनाओं को संभालने में है।

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

आप क्या सोचते हैं?

Answer 1

मैं कहूंगा कि ical मानक से शुरू होता है। यदि आप इसे अपने मॉडल के रूप में उपयोग करते हैं, तो आप Google कैलेंडर, आउटलुक, मैकिकल (प्रोग्राम), और उनके साथ लगभग तुरंत एकीकरण प्राप्त करने में सक्षम होंगे।

वहां से, आपके AJAX और जावास्क्रिप्ट cuz पर हड्डी लगाने का समय आपके पास एजेक्स और जावास्क्रिप्ट के बिना ड्रैग ड्रॉप और एकाधिक कैलेंडर के साथ एक चमकदार वेब ui नहीं हो सकता है।

Answer 2

मुझे लगता है कि मैं आपके दूसरे अनुच्छेद को समझने के लिए समझता हूं कि आप एक दूसरी घटना तालिका पर विचार कर रहे हैं जिसमें किसी घटना की प्रत्येक घटना के लिए एक पंक्ति है। मैं इससे बचूंगा।

पुनरावृत्ति घटनाओं की शुरुआत तिथि और एक स्टॉप डेट होनी चाहिए (जो घटनाओं के लिए शून्य हो सकती है जो हर एक्स दिनों को हमेशा के लिए जारी रखती है ") आपको यह तय करना होगा कि आप किस प्रकार की आवृत्ति को अनुमति देना चाहते हैं - हर एक्स दिन, प्रत्येक महीने का एनएचटी दिन, प्रत्येक दिए गए सप्ताह के दिन, आदि

मैं शायद दो टेबल की ओर रुख करता हूं - एक बार एक बार घटनाओं के लिए और आवर्ती घटनाओं के लिए एक सेकंड। आपको दो अलग-अलग पूछना और प्रदर्शित करना होगा।

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

Answer 3

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

यह दो फायदे हैं:

1. कोई जटिल दिनचर्या बाकी

आशा यह आपके लिए कुछ खाना देता प्रभावशाली बिना अगली घटना दिनांक

व्यक्तिगत घटनाओं संपादित किया जा सकता बाहर काम करने के सोचा :)

Answer 4

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

यह आपको साप्ताहिक के लिए "यह घटना हर दिन के दूसरे दिन" दिखाई देती है, "यह घटना प्रति सप्ताह के दूसरे दिन" दिखाई देती है, "यह घटना मासिक रूप से हर महीने के 5 वें दिन दिखाई देती है" यह घटना हर साल 215 वें दिन दिखाई देती है "सालाना जब तक कि तिथि समाप्ति तिथि से कम हो।

Answer 5

मुझे इन चीजों को स्टोर करने के लिए ical spec पढ़ने पर @ChanChan से सहमत होना है। पुनरावर्तनों को संभालने का कोई आसान तरीका नहीं है, खासतौर पर जिनके पास अपवाद हैं। मैंने इसे संभालने के लिए एक डेटाबेस बनाया और पुनर्निर्मित और पुनर्निर्मित किया है, और मैं वापस ical पर वापस आ रहा हूं।

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

Answer 6

@GateKiller

मैं इस मामले में जहां आप अलग-अलग घटनाओं को संपादित नहीं सोचा था। यह समझ में आता है कि आप उस मामले में अलग-अलग घटनाओं को स्टोर करेंगे।

जब आप ऐसा करते हैं, हालांकि, भविष्य में आप कितनी दूर घटनाओं को स्टोर करते हैं? क्या आप मनमाने ढंग से तारीख चुनते हैं? क्या आप भविष्य में महीनों/वर्षों में पहली बार उपयोगकर्ता द्वारा ब्राउज़ की जाने वाली नई घटनाओं को स्वतः उत्पन्न करते हैं?

इसके अलावा, आप उस मामले को कैसे संभालें जहां उपयोगकर्ता पूरी श्रृंखला को संपादित करना चाहता है। "हम एक बैठक 10:30 पर हर मंगलवार की सुबह मिला है लेकिन हम 8 पर बुधवार को बैठक शुरू करने के लिए जा रहे हैं"

Answer 7

डैरेन,

यही है कि कैसे मैं वास्तव में मेरी घटनाओं तालिका तैयार की है, लेकिन जब इसके बारे में सोचते हुए, कहें कि मेरे पास 100K उपयोगकर्ता हैं जिन्होंने ईवेंट बनाये हैं, यह तालिका बहुत कठिन हो जाएगी, खासकर अगर मैं अपने ईवेंट के लोगों को याद दिलाने के लिए ईमेल भेज रहा हूं (घटनाएं दिन के विशिष्ट समय के लिए भी हो सकती हैं!), इसलिए मैं हर 15 मिनट में इस तालिका को मतदान कर सकता हूं!

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

सवाल यह है कि, यह माध्यमिक तालिका अगले दिन या महीने के लिए होनी चाहिए? क्या अधिक समझ में आता है? चूंकि अधिकतम उपयोगकर्ता एक महीने का दृश्य देख सकता है, इसलिए मैं उस तालिका की तरफ झुका रहा हूं जो किसी दिए गए महीने के लिए सभी घटनाओं को लिखता है।

(मुझे मूल संस्करण तालिका में उपयोगकर्ता द्वारा किए गए किसी भी संपादन के लिए इस द्वितीयक तालिका को बनाए रखना होगा)।

ChanChan,

मैं यह वास्तव में कार्यक्षमता का एक ही प्रकार के साथ बनाया गया है, लेकिन मैं सिर्फ मैं कैसे घटनाओं संग्रहीत करने के बारे जाना होगा, विशेष रूप से कैसे फिर से होने वाली घटनाओं को संभालने के लिए की चर्चा करते हुए कर रहा हूँ।

Answer 8

प्रत्येक घटना के प्रत्येक उदाहरण को स्टोर करने का प्रयास ऐसा लगता है कि यह वास्तव में समस्याग्रस्त और, असंभव, असंभव होगा। अगर कोई ऐसी घटना बनाता है जो "हर गुरुवार, हमेशा के लिए" होता है, तो आप स्पष्ट रूप से सभी भविष्य की घटनाओं को स्टोर नहीं कर सकते हैं।

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

मुझे कोई भी तरीका नहीं दिखता है कि आप ऑन-डिमांड इवेंट पीढ़ी से बच सकते हैं, इसलिए मैं ईवेंट टेबल में उपयोगिता नहीं देख सकता। यदि आप इसे कैशिंग के लिए चाहते हैं, तो मुझे लगता है कि आप गलत दृष्टिकोण ले रहे हैं। सबसे पहले, यह एक खराब कैश है क्योंकि आप ऑन-डिमांड इवेंट पीढ़ी से बच नहीं सकते हैं। दूसरा, आपको शायद उच्च स्तर पर कैशिंग करना चाहिए। यदि आप कैश करना चाहते हैं, तो जेनरेट किए गए पृष्ठ कैश करें, ईवेंट नहीं।

जहां तक ​​आप अपने मतदान को अधिक कुशल बनाते हैं, यदि आप केवल 15 मिनट मतदान कर रहे हैं, और आपका डेटाबेस और/या सर्वर लोड को संभाल नहीं सकता है, तो आप पहले से ही बर्बाद हो चुके हैं। ऐसा कोई तरीका नहीं है कि आपका डेटाबेस उपयोगकर्ताओं को संभालने में सक्षम होगा यदि यह बहुत पसीना तोड़ने के बिना अधिक अधिक बार मतदान नहीं कर सकता है।

Answer 9

पहले कहा गया है, पहिया एक नए अंदाज़ में नहीं है, बस इसे बढ़ाने के लिए।

चेकआउट VCalendar, यह खुला स्रोत है, और PHP, एएसपी, और एएसपी.Net (सी #) में आता है!

इसके अलावा आप Day Pilot देख सकते हैं जो Asp.Net 2.0 में लिखे गए कैलेंडर प्रदान करता है। वे एक लाइट संस्करण प्रदान करते हैं जिसे आप देख सकते हैं, और यदि यह आपके लिए काम करता है, तो आप एक लाइसेंस खरीद सकते हैं।

अद्यतन (9/30/09):

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

Answer 10

undefined लिखा है:

है & hellip; इस तालिका, सुंदर जोर से मारा हो जाएगा, खासकर अगर मैं ईमेल भेजना उनके घटनाओं के लोगों को याद दिलाने के लिए बनने जा रही हूँ (घटनाओं के लिए किया जा सकता है दिन के विशिष्ट समय भी!), इसलिए मैं हर 15 मिनट में इस तालिका को मतदान कर सकता हूं!

अधिसूचनाओं के लिए एक तालिका बनाएं। केवल मतदान करें।

ईवेंट (आवर्ती या अन्यथा) अपडेट होने पर अधिसूचना तालिका अपडेट करें।

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

Answer 11

डेरेक पार्क, मैं एक मेज में किसी घटना के प्रत्येक उदाहरण को बनाउंगा, और यह तालिका हर महीने पुन: उत्पन्न होगी (इसलिए किसी भी घटना को 'हमेशा के लिए' पुन: स्थापित करने के लिए सेट किया गया था, एक महीने पहले पुन: उत्पन्न किया जाएगा एक विंडोज सेवा का उपयोग कर या शायद एसक्यूएल सर्वर स्तर पर)। मतदान केवल हर 15 मिनट में नहीं किया जाएगा, कि केवल ईमेल सूचनाओं से संबंधित चुनाव के लिए हो सकता है। किसी को एक महीने के लिए अपने घटनाओं को देखने के लिए करना चाहता है, मैं अपने सभी घटनाओं fetech करना होगा, और फिर से घटित घटनाओं और यह पता लगाने की जो घटनाओं को प्रदर्शित करने के (के बाद से एक फिर से घटित घटना 6 महीने पहले बनाया गया हो सकता है, लेकिन करने के लिए संबंधित एक महीने उपयोगकर्ता देख रहा है)।

जैक, मैं एक पूरी तरह से सामान्यीकृत डेटाबेस, तथ्य यह है कि मैं एक माध्यमिक तालिका पहले से ही कोई एक नियम टूट रहा है hehe बनाने की सोच रहा हूँ होने के साथ भी चिंतित नहीं हूँ। मेरी कोर डेटाबेस टेबल 'नियम' का पालन कर रही हैं, लेकिन मुझे समय-समय पर द्वितीयक तालिकाओं/कॉलम बनाने में कोई फर्क नहीं पड़ता है जब यह चीजों को प्रदर्शन के अनुसार लाभान्वित करता है।

Answer 12

इस तरह मैंने अपनी घटना तालिका वास्तव में डिज़ाइन की है, लेकिन जब इसके बारे में सोचते हैं, तो कहें कि मेरे पास 100K उपयोगकर्ता हैं जिन्होंने ईवेंट बनाये हैं, यह तालिका बहुत कठिन हो जाएगी, खासकर यदि मैं बाहर भेज रहा हूं ईमेल करता घटनाओं के लोगों को याद दिलाने के लिए (घटनाओं को भी दिन के विशिष्ट समय के लिए हो सकता है!), तो मैं मतदान इस तालिका हर 15 मिनट में संभावित हो सकता है!

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

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

उसके बाद, आप उद्देश्यों के स्केलिंग के लिए विभिन्न डेटाबेस में जानकारी विभाजन कर सकते हैं। यानी सर्वर 1-10000 कैलेंडर्स सर्वर 1, 10001 - 20000 सर्वर 2 पर मौजूद हैं,

इस तरह मैं इस तरह के समाधान को स्केल करूंगा, लेकिन मुझे अभी भी लगता है कि मैंने प्रस्तावित मूल समाधान जाने का तरीका है, यह सिर्फ इतना है कि आप इसे कैसे स्केल करते हैं जो प्रश्न बन जाता है।

Answer 13

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

इस क्वेरी आप श्रृंखला उस तत्व 3 पर शुरू होता है हो जाता है:

SELECT * FROM events WHERE id = 3 OR parentid = 3 

इस महीने के लिए सभी आइटम पाने के लिए, यह सोचते हैं कि आप एक आरंभ तिथि और अपने घटनाओं तालिका में एक अंतिम तिथि होगा, तुम सब 'क्या करना है d है:

SELECT * FROM events WHERE startdate >= '2008-08-01' AND enddate <= '2008-08-31' 

हैंडलिंग श्रृंखला के निर्माण/संशोधन प्रोग्राम के रूप में बहुत मुश्किल नहीं होगा, लेकिन यह वास्तव में सुविधा सेट प्रदान करना चाहते हैं और आप कैसे लगता है कि यह हो जाएगा पर निर्भर करेगा उपयोग किया गया। यदि आप श्रृंखला और घटनाओं के बीच अंतर करना चाहते हैं, तो आपके पास अपनी घटनाओं पर एक अलग श्रृंखला तालिका और एक शून्य श्रृंखला श्रृंखला हो सकती है, जिससे आप अपनी श्रृंखला पर नियंत्रण बनाए रखने के दौरान व्यक्तिगत घटनाओं के बारे में बात करने की स्वतंत्रता प्राप्त कर सकते हैं।

Answer 14

मैं वास्तव में इस समस्या से निपट रहा हूं, और मैंने इस धागे को पढ़ने तक iCalendar (rfc 2445) पूरी तरह से दूरी तय की है, इसलिए मुझे नहीं पता कि यह कितना अच्छा होगा या इसके साथ एकीकृत नहीं होगा।वैसे भी डिजाइन मैं अब तक लेकर आए हैं कुछ इस तरह दिखता है:

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

दोनों समस्याओं मैं इस डिजाइन के साथ देखते हैं अब तक कर रहे हैं:

1. यह MWF प्रकार की घटनाओं का प्रतिनिधित्व करने के लिए कठिन बना देता है। यह संभव है, लेकिन उपयोगकर्ता को तीन अलग-अलग आयोजनों को बनाने के लिए मजबूर करता है जो व्यक्तिगत रूप से एम, डब्ल्यू, एफ पर साप्ताहिक दोहराते हैं, और वे जो भी बदलाव करना चाहते हैं उन्हें अलग-अलग पर भी किया जाना चाहिए। इस तरह की घटनाएं मेरे ऐप में विशेष रूप से उपयोगी नहीं होती हैं, लेकिन यह मॉडल पर एक वार्ट छोड़ देता है जो मुझे पसंद से कम सार्वभौमिक बनाता है।
2. परिवर्तन करने के लिए घटनाओं की प्रतिलिपि बनाकर, आप उनके बीच संबंध तोड़ते हैं, जो कुछ परिदृश्यों में उपयोगी हो सकता है (या शायद यह कभी-कभी समस्याग्रस्त हो जाएगा।) ईवेंट तालिका सैद्धांतिक रूप से "copied_from" आईडी फ़ील्ड को ट्रैक करें जहां एक घटना उत्पन्न हुई थी, लेकिन मैंने पूरी तरह से सोचा नहीं है कि ऐसा कुछ कितना उपयोगी होगा। एक बात के लिए, माता-पिता/बाल पदानुक्रमित संबंध एसक्यूएल से पूछताछ के लिए दर्द हैं, इसलिए उस डेटा को पूछताछ के लिए लागत से अधिक लाभ उठाने के लिए लाभों को भारी भारी होना चाहिए। आप मानते हैं कि आप nested-set का उपयोग कर सकते हैं।

अन्त में मुझे लगता है कि यह संभव है सीधे एसक्यूएल का उपयोग कर एक दिया समयावधि के लिए घटनाओं की गणना करने के लिए, लेकिन मैं सटीक विवरण बाहर काम नहीं किया और मुझे लगता है कि क्वेरी आम तौर पर बहुत सार्थक होने के लिए बोझिल किया जा रहा अंत। हालांकि तर्क की खातिर, तो आपको निम्न अभिव्यक्ति अंतर की गणना करने के महीनों में भी महीने और साल के बीच एक घटना का उपयोग कर सकते हैं:

(:month + (:year * 12)) - (MONTH(occursOn) + (YEAR(occursOn) * 12)) 

पिछले उदाहरण पर भवन, आप एमओडी इस्तेमाल कर सकते हैं कि क्या में अंतर निर्धारित करने के लिए

MOD(:month + (:year * 12)) - (MONTH(occursOn) + (YEAR(occursOn) * 12), repeatIncrement) = 0 

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

Answer 15

Ra-Ajax Calendar starter-kit में रेंडरडेट ईवेंट को संभालने का नमूना है जो विशेष रूप से तिथियों को संशोधित कर सकता है। हालांकि "पुनरावर्ती घटनाएं" एक एल्गोरिदमिक चीज़ से अधिक है और यहां मुझे संदेह है कि बहुत कम कैलेंडर आपको बहुत मदद करेंगे ...

Answer 16

यदि कोई रूबी कर रहा है तो वहां एक महान लाइब्रेरी रंट है जो इस तरह की चीज करता है। बाहर की जाँच करने लायक http://runt.rubyforge.org/