Пример того, что я говорю, похож на Google Calendar. Когда создается новая повторяющаяся задача.
После создания повторяющейся задачи «шаблон», на которой основаны все отдельные задачи, вы создаете все отдельные задачи и сохраняете их в базе данных? или вы просто сохраняете повторяющиеся события «шаблона» и их исключения?
Если пользователь запрашивает представление «месяц», и вы хотите отображать все события / задачи, похоже, что создание результата в реальном времени из шаблона и включение всех исключений было бы намного более ресурсоемким, тогда, если каждая индивидуальная повторяющаяся задача была создана из шаблона и вставлена в базу данных.
Это сделает поиск / сортировку и т. Д. Намного проще.
Кто-нибудь создал что-то подобное раньше? идеи?
Храните все это в базе данных.
Вы хотите иметь таблицу «Шаблон задачи» и таблицу «Задача», где существует одно-> много отношений.
Когда пользователь указывает, что они хотят повторно выполнить задачу, создайте запись «Шаблон задачи», а затем создайте столько «Заданий», сколько пользователь указал (не позволяйте пользователю создавать задачи слишком далеко в будущем). Каждая задача связана с шаблоном задачи с помощью внешнего ключа. Идея заключается в том, что SQL будет эффективнее управлять этими записями, чем пытаться сделать все это в коде на основе одного шаблона. Таким образом, у вас будет больше возможностей при сортировке и фильтрации ваших данных. В конце концов, писать SQL-запрос проще, чем писать, тестировать и поддерживать функцию PHP, которая манипулирует данными.
Некоторые другие советы, которые я вам даю, это:
Для повторяющихся событий я сделал следующее некоторое время назад:
Когда пользователь ввел событие, я сохранил стиль даты date date GNU date – ключевое слово для PHP является относительным форматом даты .
Затем я начал с создания событий, например, в следующем году. И создали фактические записи, где я преобразовал относительную дату в фактическую – например, «каждый первый понедельник» в «мм-дд-гГГГ». Это позволило мне отобразить их, а также позволить пользователю, например, перемещать одно событие или отменять его и т. Д.
Затем выясните, как далеко продвинуться в будущее – моя идея состояла в том, чтобы создавать события, когда просматривались фактические страницы. Например, если бы я создал события до июня 2011 года, и кто-то пропустил весь путь до июля 2011 года, я бы перебирал свои события и настраивал их прозрачно.
Когда пользователь изменяет относительный шаблон, предложите обновить все последующие события – если у них уже нет настраиваемого шаблона. Относительные шаблоны позволяют легко вычислить все это.
Я прошел ту же проблему некоторое время назад, и вместо того, чтобы изобретать колесо, я использовал API Google Calendar. (http://code.google.com/apis/calendar/data/2.0/developers_guide.html)
Вы создаете учетную запись Google и получаете доступ к календарной информации. Существуют API для создания / редактирования / удаления повторяющейся записи. Кроме того, вы можете указать информацию о дате / времени и запрос для сопоставления событий.
Когда вы создаете событие в Календаре Google, вы получите маркер / идентификатор, который вы можете сохранить в своей собственной базе данных и ссылаться на него в контексте приложения.
Если пользователь запрашивает представление «месяц», и вы хотите отображать все события / задачи, похоже, что создание результата в реальном времени из шаблона и включение всех исключений было бы намного более ресурсоемким, тогда, если каждая индивидуальная повторяющаяся задача была создана из шаблона и вставлена в базу данных.
Я бы не согласился на это. Что делать, если задача повторяется каждую субботу в течение следующих 7 лет … И что, если бы было много этих повторяющихся задач? Это будет стоить вам много места для отходов. Поэтому я считаю, что лучше сохранить повторяющуюся задачу как одну запись + одну запись для каждого исключения (так как есть меньше исключений, чем повторений).
Ну, единственная проблема заключается в том, как настроить запрос для выбора каждой задачи (все еще думая об этом)