मैं एक ऐसी प्रणाली का निर्माण कर रहा हूं जिसे विभिन्न प्रकार की घटनाओं को स्टोर/प्रबंधित करने की आवश्यकता है। सादगी के लिए, मैं कैलेंडर तैयार करने पर ध्यान केंद्रित करूंगा (मैं कुछ अलग बना रहा हूं, लेकिन कैलेंडर एक अच्छा सादृश्य है और इसके बारे में तर्क करना आसान है)। मैं संभावित डेटाबेस/स्कीमा डिजाइन विचारों के बारे में सुनना चाहता हूं।अपवादों के साथ पुनरावर्ती घटनाओं के लिए डेटाबेस डिज़ाइन
समस्या विवरण
मैं घटनाओं के विभिन्न प्रकार के साथ एक कैलेंडर है (सादगी के लिए, कहते हैं कि घटना का केवल 1 प्रकार है: टास्क)। उपयोगकर्ता किसी विशेष तिथि के लिए नया ईवेंट जोड़ सकता है, संपादित कर सकता है (कुछ विवरण बदल सकता है, जैसे शीर्षक या किसी अन्य तारीख पर जाना) या हटाएं। एक बार की घटनाएं और पुनरावर्ती घटनाएं हो सकती हैं (विभिन्न प्रकार के पुनरावृत्ति के साथ: प्रत्येक एक्स दिन, महीने के हर 15 वें दिन, हर सप्ताह सोमवार को; सरल क्रॉन की तरह)। जब उपयोगकर्ता आवर्ती ईवेंट चलाता है, तो इस घटना के अन्य सभी उदाहरण उसी तरीके से स्थानांतरित होते हैं (उदा: +3 दिन)। महत्वपूर्ण हिस्सा: पुनरावर्ती घटनाओं में अपवाद हो सकते हैं। तो, उदाहरण के लिए, मान लीजिए कि मेरे पास एक पुनरावर्ती घटना ए है जिसे हर 7 दिनों में दोहराया जाता है। लेकिन मैं अगले सप्ताह के लिए अपनी तारीख बदलना चाहता हूं, इसलिए मंगलवार की बजाय, इसे शुक्रवार को सौंपा जाएगा, इसके बाद भी यह मंगलवार को होगा। "अभिभावक" ईवेंट स्थानांतरित होने पर यह "अपवाद" ईवेंट प्रभावित नहीं होना चाहिए।
इसके अलावा, प्रत्येक पुनरावर्ती घटना में अतिरिक्त जानकारी हो सकती है, जो केवल 1 विशेष उदाहरण से संबंधित है, उदाहरण के लिए: मेरे पास एक ही पुनरावर्ती घटना है, हर 7 दिनों में दोहराया जाता है, मैं इस सप्ताह के उदाहरण के लिए एक नोट जोड़ना चाहता हूं जो कहता है " एक्स ", और मैं अगले महीने इवेंट ए के लिए एक और नोट जोड़ना चाहता हूं जो" वाई "कहता है - वे फ़ील्ड केवल उसी उदाहरण के लिए दृश्यमान हैं।
विचार नियमित रूप से, एक बार वाले ईवेंट के साथ
सिस्टम बिल्कुल स्पष्ट इसलिए मैं उस पर चर्चा नहीं करेंगे और पुनरावर्ती ईवेंट पर ही ध्यान केंद्रित है।
1. एक संभव समाधान एक ही है कि OOP जैसा दिखता है: मैं एक Event
ऐसे start_date
के रूप में, end_date
(null
हो सकता है) क्षेत्रों के साथ "वर्ग", recurrence_type
(EVERY_X_DAYS
के संभावित मूल्यों के साथ enum की तरह कुछ हो सकता है, DAY_OF_WEEK
, DAY_OF_MONTH
) और recurrence_value
(7
कहें)। जब उपयोगकर्ता नई आवर्ती घटना जोड़ता है, तो मैं डेटाबेस में ऐसे Event
बना देता हूं। जब उपयोगकर्ता इस घटना की 1 घटना को बदलना चाहता है, तो मैं प्रकार/वर्ग MovedEvent
के डीबी में नई प्रविष्टि जोड़ता हूं जो अलग-अलग तारीख के साथ Event
से "विरासत" प्राप्त करता है और related_to
अतिरिक्त फ़ील्ड है जो ID
(या UUID
पर इंगित करता है, यदि आप करेंगे) Event
का यह है कि यह संबंधित है। लेकिन साथ ही, मुझे सभी MovedEvent
s का ट्रैक रखने की आवश्यकता है (अन्यथा मेरे पास एक ही सप्ताह में 2 ईवेंट प्रदर्शित होंगे), इसलिए मुझे ID
एस के moved_events
की आवश्यकता है जो सभी MovedEvent
एस पर इंगित करता है। नुकसान: हर बार जब मैं कैलेंडर प्रदर्शित करना चाहता हूं तो मुझे Event
प्राप्त करने की आवश्यकता है और moved_events
से सभी घटनाओं का चयन करें, जो कि अगर मेरे पास बहुत से स्थानांतरित कार्यक्रम होंगे तो इष्टतम नहीं है।
2. एक और विचार प्रत्येक घटना को एक अलग रिकॉर्ड के रूप में स्टोर करना है। आईएमओ यह एक भयानक विचार है, लेकिन मैं बस इसका उल्लेख कर रहा हूं क्योंकि यह एक संभावना है। नुकसान: हर बार जब मैं मुख्य कार्यक्रम को संपादित करना चाहता हूं (उदाहरण: मैं "हर 7 दिनों" से "हर 9 दिनों" में होने वाली घटना को बदलना चाहता हूं) मुझे घटना की हर घटना को बदलने की जरूरत है। हालांकि, "अपवाद" (एकल उदाहरण बदलना) आसान है।
एसक्यूएल/नोएसक्यूएल? स्केल विवरण
मैं अपने प्रोजेक्ट में पोस्टग्रेएसक्यूएल का उपयोग कर रहा हूं, लेकिन मेरे पास नोएसक्यूएल डेटाबेस में बुनियादी ज्ञान है और यदि वे इस तरह की किसी समस्या के लिए बेहतर अनुकूल हैं, तो मैं इसका उपयोग कर सकता हूं।
स्केल: मान लें कि मेरे पास 5k उपयोगकर्ता हैं, और प्रत्येक के पास औसत 150 घटनाएं/सप्ताह होंगे, जिनमें से 40% "अपवाद" हो सकते हैं। इसलिए मैं इस प्रणाली को कुशल होने के लिए डिजाइन करना चाहता हूं।
इसी तरह के सवाल & अन्य संसाधन
मैं सिर्फ पढ़ने मार्टिन फाउलर की "कैलेंडर के लिए पुनरावर्ती ईवेंट" शुरू कर दिया है (http://martinfowler.com/apsupp/recurring.pdf), लेकिन मुझे यकीन है कि अगर यह मेरी समस्या पर लागू होता है नहीं कर रहा हूँ और अगर ऐसा है, कैसे एक इस दस्तावेज़ के अनुसार डेटाबेस स्कीमा डिजाइन करेगा (सुझाव स्वागत है)।
इसी तरह के सवाल कर रहे हैं, लेकिन मैं "अपवाद" (अन्य को प्रभावित किए बिना बदल रहा है 1 घटना उदाहरण) का कोई उल्लेख नहीं देखा, लेकिन शायद किसी को इन कड़ियों उपयोगी लगेगी:
Design question: How would you design a recurring event system?
What is the best way to represent "Recurring Events" in database?
एक लंबे प्रश्न के लिए क्षमा करें, मैं इस समस्या को अच्छी तरह से वर्णन करने के लिए करना चाहता था। फिर भी, मुझे लगता है कि यह बहुत अराजक है, इसलिए यदि आपके पास अतिरिक्त प्रश्न हैं, तो मैं खुशी से अधिक जानकारी प्रदान करूंगा। फिर, मैं संभावित डेटाबेस/स्कीमा डिजाइन विचारों के साथ-साथ किसी भी अन्य सुझावों के बारे में सुनना चाहता हूं। धन्यवाद!
हे आपके अनुभव को साझा कर सकता है कि आपने इसे कार्यान्वित करने के लिए या कुछ युक्तियों को कैसे कार्यान्वित किया। – user3775217
हैलो, मैं इस मुद्दे से भी निपट रहा हूं। मैंने प्रत्येक बार-बार होने वाली घटना के लिए अलग-अलग ईवेंट प्रविष्टियों के ब्लंट समाधान के साथ जाने का निर्णय लिया है। मेरे इवेंट सिस्टम में प्रत्येक घटना घटना के लिए अलग-अलग आरएसवीपी, भुगतान और टिप्पणियां जैसी गतिविधि होती है, और प्रत्येक घटना की घटना में इसकी अपनी अनूठी घटना आईडी, सर्वोच्च प्राथमिकता होनी चाहिए। यह अकेले मेरी पसंद को आसान बनाता है, मुझे प्रत्येक ईवेंट को अलग से स्टोर करना होगा। प्लस तरफ, मेरी उपयोगकर्ता आधार गतिविधि एक समय में केवल कुछ महीने होती है, इसलिए मैं एक ऑटो-एक्सपिरिशन नियम (उदा।3 महीने अधिकतम) जो डीबी प्रसंस्करण के समय प्रबंधनीय रखेगा। – MarsAndBack