هل يجب علي تخزين التواريخ أو قواعد التكرار في قاعدة البيانات الخاصة بي عند إنشاء تطبيق تقويم؟

Question

أقوم ببناء موقع تقويمي (ASP.NET MVC) التطبيق (فكر في إصدار بسيط من Outlook) وأريد أن أبدأ في دعم أحداث التقويم المتكررة (شهريًا ، سنويًا ، إلخ)

في الوقت الحالي ، أقوم بتخزين التواريخ الفعلية في بلدي ولكني أردت معرفة ما إذا كان من المنطقي ، مع تكرار ، من المنطقي الاستمرار في تخزين التواريخ (مع بعض القطع الواضح) ، أو ينبغي أن أخزن خيارات التكرار وتوليد التواريخ أثناء الطيران .

لقد جعلني أفكر في كيفية قيام Outlook أو Google Mail و ETC بذلك أو أي خدمة أخرى تدعم العناصر التقويمية المتكررة.

هل هناك أي اقتراحات حول هذا؟

Answer 1

افصل بياناتك إلى جزأين: البيانات "الكنسي" (قاعدة التكرار) و "التقديم" (تواريخ تم إنشاؤها ؛ بقراءة فقط من التجديد). إذا تغيرت البيانات الكنسية ، فتجدد بيانات "التقديم" في تلك المرحلة. للتكرار اللانهائي ، احتفظ ببعض الحالات وإنشاء المزيد إذا نفد (على سبيل المثال ، إذا نظر المستخدم إلى التقويم الخاص به لعام 2020).

إذا كان لديك سرعة معالج لا حصر لها ، فأنت بحاجة فقط إلى البيانات الكنسي - ولكن في الواقع ، تقوم بجميع المعالجة/الوقت لجميع قواعد التكرار على كل من المحتمل أن تكون عرض الصفحة مستهلكة للوقت ... لذا فأنت تتبادل بعض التخزين (والتعقيد) لتوفير هذا الحساب المتكرر. عادة ما يكون التخزين رخيصًا جدًا ، مقارنة بالحساب المطلوب لعدد كبير من الأحداث. اذا أنت فقط تحتاج إلى تخزين تواريخ الأحداث ، وهذا أمر رخيص جدًا حقًا - يمكنك بسهولة استخدام عدد صحيح من 4 بايت لتمثيل تاريخ ، ثم توليد تاريخ/وقت كامل من ذلك ، على افتراض أن التكرار الخاص بك كلها قائمة على التاريخ. بالنسبة للتكرار القائم على الوقت (على سبيل المثال "كل ثلاث ساعات") ، يمكنك أن تمثل 8 بايتات من UTC - 8 بايت وصولاً إلى دقة جيدة جدًا طالما أنك من المحتمل أن تحتاجها.

يجب أن تكون حذراً في الحفاظ على الصلاحية على الرغم من ذلك - إذا تغير الاجتماع المتكرر اليوم, ، هذا لا يتغير عندما يكون ذلك لديها حدث في الماضي ... لذلك ربما تريد ذلك ايضا لديك بيانات القراءة فقط حول عندما حدثت التكرار بالفعل. من الواضح أنك لن ترغب في ذلك للحفاظ على الماضي إلى الأبد ، لذلك ربما ترغب في "جمع القمامة" لأحداث أكثر من بضع سنوات ، اعتمادًا على قيود التخزين الخاصة بك.

قد تحتاج أيضًا إلى القدرة على إضافة ملاحظات واستثناءات (على سبيل المثال "لا يحدث الاجتماع اليوم بسبب عطلة عامة" أو "انتقل إلى الساعة 4 مساءً") على أساس كل شيء. هذا يصبح هل حقا المرح عند تغيير التكرار - إذا قمت بتغيير "كل يوم اثنين" إلى "كل يوم ثلاثاء" ، فهل تحتفظ بالاستثناءات أم لا؟ كيف يمكنك حتى مطابقة الاستثناءات عندما تتغير من "كل يوم" إلى "كل أسبوع"؟ هذه ليست أسئلة تتعلق مباشرة بالتخزين - لكن قرارات التخزين ستؤثر على مدى سهولة تنفيذ أي سياسة تقررها.

Answer 2

ستحتاج إلى التعامل مع الأحداث والأحداث بشكل منفصل.

الحكم الحكيم: بالنسبة للأحداث ، ستحتاج إلى تخزين قواعد إعادة التكرار (والتي يمكن أن تكون rrule مثل المحددة بواسطة RFC5545 ولكن أيضًا مجموعة صريحة من التواريخ مثل RDATE في RFC5545) ولكن أيضًا استثناءات (انظر exdate of RFC5545 وربما exrule كما في RFC2445) . ستحتاج أيضًا إلى تتبع التغييرات في هذه القواعد: التغييرات في RDATE ، لا توجد مشكلة عند حدوثها في المستقبل وأن يتم تجاهلها في التواريخ السابقة. التغييرات في RRULE أكثر صعوبة حيث تؤثر على الأحداث السابقة. تفضيلي الشخصي هو إضافة خاصية محددة لـ RRULE القديمة والجديدة لتحديد تاريخ بدء وإنهاء كل منهما.

إذا كان للحدث فترة زمنية محدودة (قل العد أو حتى موجود الممتلكات) ، فيجب عليك تخزين البدء والانتهاء في طاولتك للسماح بسهولة الاستعلام عن الأحداث (خاصة عند البحث عن حوادث خارج نافذة الزمن المسبق (انظر أدناه). يمكن أن تساعد في تقليل عدد الأحداث التي يجب إعادة البيع من أجلها).

الحوادث الحكيمة: في الحالات ، يجب عليك تخزين الحالات داخل نافذة محددة مسبقًا حولها (على سبيل المثال +/- 6 أشهر أو 12 شهرًا وتم حسابها بشكل منتظم) والحفاظ على سجلات هذا للسماح بإعادة الحساب إذا أراد المستخدمون رؤية المزيد في المستقبل (لقضايا العروض). يجب عليك أيضًا التفكير في حساب الفهرس (معرف التكرار) للمساعدة في العثور على السهولة في الحدوث التالي.

أقل في الواجهة الخلفية ولكن أكثر في الواجهة الأمامية ، يجب عليك أيضًا تتبع تغييرات tzid لتسأل المستخدم إذا كان هناك حدث تم جدولة تم تحديثه (فكر في شخص ما في جزيرة ساموا التي سجلت اجتماعًا لعقد اجتماع يوم الجمعة ، 30 ديسمبر 2011 قبل أن تقرر البلاد هذا اليوم) ، بالمثل ، يمكنك أن تسأل ما إذا كان الحدث الذي يحدث خلال وقت توفير النهار "لا يُقصد به" أبدًا " تحدث "أو" تحدث مرتين "(المزيد حول هذا الموضوع هنا)

ملاحظة: قد ترغب في النظر في الدعم بما يتجاوز ما هو محدد في RFC5545 من حيث قواعد التكرار وأيضًا إضافة دعم للقواعد المتكررة الدينية ( شاهد مقدمة USNO للتقويمات أو في الطباعة "الحسابات التقويمية" (الطبعة الثالثة) من E. Reingol و N. Dershowitz).

نظرًا لأنك تسأل عن التنفيذ الحالي ، يمكنك التحقق من مخطط قاعدة البيانات بسهولة من Sunbird (SQLite) أو Apple Open Source Server وخادم جهات الاتصال, ، قائمة أكثر اكتمالا من المشاريع المفتوحة المصدر الحالية لخوادم Caldav (والتي ربما تكون مجموعة فرعية لما تبحث عنه) متوفرة) هنا)

Answer 3

اضطررت إلى بناء نظام عمل مع الجدولة وفعلنا كلاهما. هذا ما لدينا

• مجموعة من الجداول التي حافظت على تتبع الجدول.
• جدول استمر في تتبع الحالات السابقة من الجدول (عندما حدثت بالفعل)
• جدول حافظ على تتبع المثيل الأخير والحادي عشر (عندما يكون العنصر التالي بسبب حدوثه استنادًا إلى آخر مرة) ، لا تحتاج إلى هذا الجدول ، لكننا استخدمناه ، لأنه بخلاف ذلك ، ستحسب باستمرار ما إذا كان يجب على عنصر ما إذا أن تحدث الآن

مع الجدولة ، يمكن أن تصبح الأمور صعبة للغاية لأنك يجب أن تتذكر أنه في أي وقت من الأوقات ، يمكن أن يتغير الجدول. أيضًا ، قد يكون هناك عنصر مستحق عند عدم تشغيل التطبيق الخاص بك ، وعندما يبدأ مرة أخرى ، تحتاج إلى معرفة كيفية تحديد العناصر السابقة.

أيضا ، تأكدنا من أن الجداول التي تابعت الجدول الفعلي وقفت وحدها. والسبب في ذلك هو أن هذه هي المجموعة الأكثر تعقيدًا من الجداول في النظام وأردنا أن نكون قادرين على إعادة استخدامها حتى يمكن استخدامها لأشياء مختلفة تحتاج إلى جدولة. مثل إرسال رسائل البريد الإلكتروني للمسؤول ، وإرسال الإخطارات ، وصيانة الخادم مثل تنظيف ملفات السجل.

Answer 4

بالتأكيد سأستخدم خيارك الثاني. استخدم خيارات تكرار مختلفة ، وقم بتخزينها بشكل منفصل وحسابها أثناء الطيران. سيكون تخزين جميع هذه التواريخ عبارة عن حمولة قارب من البيانات غير الضرورية.

إليك إجابة جيدة لتكمل سؤالك.
بنية البيانات لتخزين الأحداث المتكررة؟

أيضا ، كملاحظة جانبية. لقد بدأت في تخزين كل شيء كوقت UTC بحيث يكون لديك خط أساسي مشترك إذا كنت بحاجة إلى استخدام مناطق زمنية متعددة.

Answer 5

واجهت مشكلة مماثلة في تطبيق الويب الذي قمت به قبل بضع سنوات (قد يكون هناك طريقة أفضل الآن :)). كنت أرغب في تضمين جدولة كان لها جميع وظائف الأحداث المتكررة ، ووقت المقبض ، والأيام ، والأسابيع ، والشهور ، والسنوات ، والاستثناءات ، حتى أتمكن من الحصول على قواعد مثل:

1) كل يوم في الساعة 10 صباحًا باستثناء الأربعاء

2) كل ساعتين بحد أقصى 4 تكرارات يوميًا

3) كل يوم الاثنين الأول من الشهر

إلخ..

كان تخزين التواريخ/الأوقات المتكررة ممكنًا ، ولكن غير مرن. كل تكرار للحدث الخاص بك يتغير عندما يكون "الحد الأقصى". وإلى أي مدى تنظر؟

في النهاية ، كتبت فئة جدولة مخصصة يمكنها القراءة والكتابة إلى سلسلة. كانت هذه هي السلسلة التي تم تخزينها في قاعدة البيانات ومن ثم يمكن استدعاء وظيفة بسيطة لمعرفة متى يكون الحدوث التالي.

Answer 6

تحتاج إلى تخزين بعضهم بالتأكيد. قد يقوم المستخدم بتحرير أحد الأحداث ، تاركًا للآخرين دون أن يمسوا (ربما استوفت السؤال: "هل تريد تحرير جميع الأحداث المتكررة أو فقط هذه الأحداث؟" في بعض التقويمات ، أي Windows Mobile).

قد ترغب أيضًا في تخزين الأحداث السابقة وعدم إزالتها عندما يقوم المستخدم بحذف الحدث المتكرر.

إذا قمت بتخزين جميع الآخرين أو إنشاءها ، فهو تفاصيل تنفيذ. أفضل توليدها ، إن أمكن.

على أي حال ، ستحتاج إلى بعض معرف الحدث المتكرر المخزن مع كل حدث ، بالإضافة إلى بعض العلامات التي تخبرك إذا تم تعديل الحدث لاحقًا. أو في نهج أكثر تعقيدًا ، علامة لكل خاصية للحدث ، إذا كانت القيمة الافتراضية (من الحدث المتكرر) أو إذا تم تعديلها لهذه الحالة بالذات. ستحتاج إلى هذا عندما يقرر المستخدم تحرير الحدث المتكرر.

Answer 7

لاحظ أن معظم الردود تميل نحو حفظ البيانات التي تم إنشاؤها. ولكن تأكد من أنك تفكر في حالة الاستخدام الخاصة بك.

مرة أخرى في الأيام كانت خوادمي محدودة من قبل IO مع الكثير من وحدة المعالجة المركزية لا تفعل شيئًا. في الوقت الحاضر ، لديك SSD (إذا كنت تستطيع تحمل تكاليف ذلك ، وإلا فإن يسارك مع HD الغزل القديم) ولكن لاحظ أن العدد الأساسي قد زاد أيضًا.

إن الشيء الجميل في هذا النوع من العمليات الحسابية هو أنه يمكنك تقسيمها بسهولة ومنحها للعديد من النوى أو حتى لبعض الخوادم الرخيصة في شبكة محلية. في كثير من الأحيان أرخص من إعداد مجموعة NOSQL أو الذهاب إلى مجموعة قاعدة البيانات الكاملة.

والبديل قد يكون أيضًا ذاكرة التخزين المؤقت ، مجرد ذاكرة التخزين المؤقت للتقويم الخاص بك ، لا داعي للقيام بجميع الحسابات في كل مرة لم يتغير فيها شيء.

ولكن كما قال ذلك يعتمد على حالة الاستخدام الخاصة بك. لا تتبع فقط الإجابات المذكورة أعلاه ولكن قم بإجراء حساباتك الخاصة إذا كان لديك وقت واتخاذ قرار.