Разметка схемы базы данных для календарного приложения
другим простым методом будет
$max = array_map( function( $arr ) {
global $last;
return (int)( ( $arr["Total"] > $last ) ? $arr["Total"] : $last );
}, $array );
print_r( max( $max ) );
3 ответа
Недавно я создал приложение-календарь, и это была одна из многих проблем, с которыми я столкнулся.
В конце концов я придумал полу-хакерское решение. Я создал столбец event_type . В этом столбце у меня было либо: ежедневно , еженедельно , ежемесячно или ежегодно . У меня также были столбцы start_date и end_date . Все остальное обрабатывалось в реальном внутреннем коде.
Я никогда не пытался разделить событие, если пользователь редактировал только одно событие. В данной ситуации в этом не было необходимости. Однако вы можете разделить событие, изменив end_date первого, создав новое событие с новой start_date и end_date оригинала, и, наконец, новое событие для того, которое вы только что выбрали для редактирования. Этот процесс закончится созданием трех событий.
Хакерство, я знаю. В то время я не мог придумать умного способа решить эту проблему.
Удерживайте повторяющийся элемент в таблице событий как обычно , но помечены как повторяющиеся с соответствующими датами начала и окончания.
Если пользователь изменяет один экземпляр встречи, просто создайте новое событие, возможно, с 'parentId', равным идентификатору повторяющегося события.
Создайте логику, которая заставляет календарь переопределять любые повторяющиеся события в определенный день событиями с соответствующими родительскими идентификаторами.
Ваш вопрос о производительности - это, в основном, старая скорость vs. проблема хранения. Я действительно не думаю, что требуемый расчет превысит пространство, необходимое для хранения такого количества встреч. Просто прочтите об оптимизации базы данных, индексации и т. Д.
Не могли бы вы соединить два мира с помощью таблицы «кеша», в которой вы предварительно вычислите следующий События на X дней?
Итак, три таблицы:
recurring_event_specs
one_time_events
cached_recurring_events
Для любой части календаря в течение X дней от сегодняшнего дня ваш запрос будет UNION one_time_events и cached_recurring_events .
Тогда вам нужно будет производить вычисления даты на лету только в том случае, если пользователь попытается просмотреть часть календаря более чем через X дней в будущем. Я полагаю, вы могли бы найти нормальный X, который охватил бы большую часть нормального использования.
Таблица cached_recurring_events должна обновляться всякий раз, когда пользователь добавляет новое повторяющееся событие - и, возможно, раз в день в автономном режиме , с помощью задания cron / запланированного задания. Но только в те дни, когда не создавалось новых повторяющихся событий.