iCal backend - повторяющиеся даты

Question

Я создаю систему календаря, используя FullCalendar в качестве переднего конца. Бэкэнд будет MySQL/PHP.

Он будет хранить список общедоступных назначений для пользователей, которые создаются и вставляются приложением. Эти встречи будут единственным событием, которое начнется и завершится в тот же день. Кроме того, пользователи смогут отмечать их несоблюдение в календаре из-за личных обязательств. Эта последняя функциональность требует использования повторяющихся событий. Вместо того, чтобы повторно изобретать колесо, я смотрел на использование структуры, основанной на iCal. Этот пост был очень полезен ical-field-list-for-database-schema-based-on-ical-standard при определении структуры базы данных.

Я создал форму заявки, которая позволяет пользователю вводить необходимые данные для хранения частной одиночной/повторяющейся встречи. После отправки формы данные отправляются через Ajax на сервер. Я нашел отличный PHP-скрипт, который генерирует массив повторяющихся дат на основе параметров, введенных пользователем, либо в их родном формате, либо с использованием RRULE.

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

Достаточно ли хранить все события в формате iCal и иметь возможность получать события по запросу? Проблема, которую я предвижу, заключается в том, что повторяющиеся события нелегко искать, поскольку их параметры должны быть расширены «на лету»? Я рассматривал возможность создания второй таблицы каждого отдельного события (сгенерированного) со ссылкой на исходный RRULE, который его создал. Я хотел бы ограничить количество повторяющихся дат, которые могут вводить пользователи, чтобы пользователи не входили в мероприятие каждый день в течение следующих 100 лет! Я думаю, что этот подход также позволил бы мне редактировать отдельные события, которые были первоначально созданы повторяющимся правилом.

Это хороший подход, или есть лучший способ?

Answer 1

Посмотрите when building a calendar app, should i store dates or recurrence rules in my database?.

Вы должны сохранить rrule, exrule, rdate и exdate, связанные с информацией о достоверности (чтобы отслеживать изменения с течением времени: например, если ваши пользователи могут захотеть оглянуться назад в прошлом, когда они имели определенное событие, и если rrule изменился между появлением и точкой времени, когда он/она оглядывается назад), Для событий, которые имеют конечное число вхождений, делают предварительное вычисление начала и конца для временного окна для более простых запросов и имеют окно перехода для в котором у вас есть все события в таблице. Когда пользователи ищут вхождения из временного окна (должно быть редко, чтобы люди смотрели более одного года назад или более одного года в будущем), вы вычисляете релевантные события, специфичные для окна времени, которое пользователи запрашивают и генерируют на лету ,

Answer 2

Как насчет таблицы по следующим направлениям:

CREATE TABLE RecurringAppointments (
    startdate DATE NOT NULL, 
    enddate DATE, 
    freq  INT NOT NULL, -- contains #days between each occurrence 
    -- etc. 
) 

Затем, чтобы извлечь все такие назначения, которые происходят на данном thedate:

SELECT * FROM RecurringAppointments 
WHERE 
     thedate BETWEEN startdate AND enddate 
    AND DATEDIFF(thedate, startdate) % freq = 0;