Повторяющиеся события, как их хранить?

Question

Я нашел несколько вопросов, заданных перед рассмотрением повторяющихся событий, но я не ушел в один, который приближается к моей потребности. Я изо всех сил пытаюсь понять, как бороться с повторяющимися событиями для системы уведомлений.

Я знаю, что из двух вариантов до сих пор:

1. магазин одного события, которое имеет структуру, в нем и рассчитывать на лету любое будущее событие (что-то вроде повторения навсегда, и т.д.). Используйте шаблоны cron или даже лучшие вещи RRULE.

2. Хранить все будущие события как отдельные события до определенной даты.

Моя проблема с вариантом 1 в том, что мне нужны события, чтобы провести некоторые другие данные, такие как подтверждения, и если у меня есть повторяющееся событие, я, возможно, потребуется провести несколько подтверждений для каждого повторяющегося события. Это превращается в неприятный хак, чтобы заставить все работать, и я даже не хочу думать о том, как иметь дело с отображением прошлых и будущих событий, связанных с другими данными.

Вариант 2 лучше, так как я могу хранить все дополнительные данные, связанные с каждым, даже в одном событии. Проблема связана с рассмотрением будущих событий. Во-первых, если событие повторяется навсегда, чем сколько я должен идти для хранения событий. Я просто делаю куски и создаю «на лету», если пользователь хочет отобразить будущее событие, которое еще не было создано? Этот вариант также кажется взломанным.

До сих пор я немного читал о RRULE и обнаружил, что могу использовать rrule.js для интерфейса и несколько других пакетов для бэкэнд.

Редактировать 1: чтобы лучше прояснить, я не полностью настроен на использование полных стандартов формата iCal и думаю только использовать RRules. Но я мог бы изменить свое мнение, так как я все еще ищу варианты.

Как iCal Vevents и rrules должны храниться в БД?

Answer 1

Непонятно, заботитесь ли вы о rrule только как удобный способ выразить что-то, что повторяется, или вы хотите использовать полный формат iCalendar.

Предполагая, что более поздний вариант Вариант 1 покрыт RFC5545: вы должны сохранить «главный» VEVENT, содержащий базовую информацию, вместе с RRULE, + один VEVENT для каждого экземпляра, который является «исключением» для базового события , где каждое исключение идентифицируется его идентификатором RECURRENCE.

В RFC5545 нет никакого примера такого события, но у RFC5546 есть что-то довольно близко к https://tools.ietf.org/html/rfc5546#section-4.4.8 (используя RDATE вместо RRULE и не нужно свойство METHOD, но вы получите эту идею).