Лучшая практика для конкретной ситуации запроса даты MySQL - PullRequest
Новая
       7

Лучшая практика для конкретной ситуации запроса даты MySQL

1 голос
/ 20 июня 2011

Мне нужно реализовать довольно сложный запрос, основанный на нескольких опциях дат в Zend / MySQL, и я был бы рад получить совет от людей, которые не так застряли в моем коде, как я:)

Iу меня есть таблица "event_dates" с описаниями дат, привязанными к модели событий в моем приложении.Каждое событие может иметь несколько дат событий, и они могут иметь довольно сложные настройки.

Настраиваемые и соответствующие этому вопросу параметры следующие:

  • Дата исправления
  • Диапазон дат (date_from, date_to)
  • Диапазон дат, основанный на «в определенные дни недели»
  • Диапазон дат, основанный на «каждую n-ю неделю» (каждую 2-ю неделю, оставляя один раз каждыеочередь)
  • Диапазон дат на основе «каждого n-го дня недели в месяце» (второй понедельник)
  • и, конечно, каждой их комбинации.

Iя пытаюсь записать запросы перед их кодированием, поэтому у меня есть четкое представление о том, что нужно, но есть некоторые комбинации, которые я просто не могу понять, чтобы обработать без предварительного кодирования списка возможных дат.

Как бы вы это реализовали - теоретически, не спрашивая конкретный код здесь (пока :)).Вы бы создали список возможных попаданий в PHP, а затем запросили бы их более простым способом, или вы бы предпочли сделать сложный запрос из двадцати, где-то и так далее?

Спасибо за ваше время

  • Арне

PS: Это может быть полезно -> 

CREATE TABLE `event_dates` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `events_id` int(11) NOT NULL,
  `datetime_from` datetime DEFAULT NULL,
  `datetime_to` datetime DEFAULT NULL,
  `date_from` date DEFAULT NULL,
  `date_to` date DEFAULT NULL,
  `time_from` time DEFAULT NULL,
  `time_to` time DEFAULT NULL,
  `date_type` tinyint(4) NOT NULL DEFAULT '0',
  `frequency_in_weeks` tinyint(4) DEFAULT NULL,
  `nth_wday_in_month_week` tinyint(4) DEFAULT '0',
  `nth_wday_in_month_wday` tinyint(4) NOT NULL DEFAULT '0',
  `is_mondays` tinyint(1) NOT NULL DEFAULT '0',
  `is_tuesdays` tinyint(1) NOT NULL DEFAULT '0',
  `is_wednesdays` tinyint(1) NOT NULL DEFAULT '0',
  `is_thursdays` tinyint(1) NOT NULL DEFAULT '0',
  `is_fridays` tinyint(1) NOT NULL DEFAULT '0',
  `is_saturdays` tinyint(1) NOT NULL DEFAULT '0',
  `is_sundays` tinyint(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8;

Ответы [ 2 ]

1 голос
/ 20 июня 2011

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

Для этой части приложения было две таблицы ... одна для хранения информации о событии (заголовок, описание и т. Д.) И одна для каждого ее экземпляра (идентификатор, дата / время начала, дата / время окончания). и т. д.).

Недостатком является то, что события действительно должны закончиться в какой-то момент в будущем, будь то через месяц или через 50 лет. Вы можете выбрать произвольную дату в будущем для «бесконечно повторяющихся» событий, но это зависит от вашего приложения, подходит ли это или нет.

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

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

0 голосов
/ 20 июня 2011

Как насчет использования API календаря Google? В Google есть поддержка повторяющихся событий всех видов, и в Zend Framework уже есть встроенная библиотека. http://framework.zend.com/manual/en/zend.gdata.calendar.html

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

...