Я разрабатываю еженедельное календарное представление только для чтения событий пользователей. Столбцы - это дни недели (mon > sun) Строки - это временные интервалы (8:00 > 9:00, 9:00 > 10:00... с 8:00 до 7 вечера).
Вопрос: какой лучший подход для создания этого пользовательского календаря:
Вариант 1: чистый SQL Я даже не знаю, возможно ли это, но я бы нашел его чрезвычайно элегантным: mysql создаст таблицу с 7 столбцами (дни) и 11 строк (временные интервалы) и подзапросы для каждого временного интервала, проверяя, есть ли собрание, зарезервированное для этого временного интервала/пользователя.
вариант 2: php/mysql mysql просто извлекает забронированные/пользовательские встречи и перекрещивает их с календарем, созданным php.
Возможно ли вариант 1? Если это так, это ресурсоемкий?
Спасибо, Александр
ОБНОВЛЕНИЕ: ПРЕДЛОЖЕНИЯ ЗАПРОСА
Вот запрос "Вариант 2", который я использую для получения забронированных событий (уроки в этом случае: пользователь - учитель).
SELECT DISTINCT date, hour_from, hour_to, courses.description, courses.alias, teachers.name, locations.new_acronym
FROM timetables
INNER JOIN courses ON (courses.id=timetables.course_id)
INNER JOIN teachers ON (teachers.id=timetables.prof_id)
INNER JOIN locations ON (locations.id=timetables.location_id)
WHERE ((timetables.prof_id='$id')
AND (timetables.date >= '$starting_date')
AND (timetables.date < date_add('$starting_date', INTERVAL 7 day))) ;
Я очень заинтересован в предложениях по запросу, которые сделают работу с параметром 1!
Попытка описать календарь как таблицу SQL не похожа на хорошее совпадение. Конечно, можно выполнить запрос, который будет генерировать таблицу с 7 столбцами и 11 строками, но тогда что бы вы сделали с этой сгенерированной таблицей? Вам все равно придется отображать его с помощью PHP.
Итак, начните с предположения, что PHP создает календарь, и избавляйтесь от дополнительной работы по созданию SQL для генерации одного (и чрезвычайно конкретного) заранее. Таким образом, вы можете использовать один запрос SQL для извлечения всех событий, которые должны быть видны одним выстрелом, а затем поместить их в календарь по мере его рисования.
Я предполагаю, но я думаю, что вы можете сделать вариант 1, если вы создадите таблицу с временными слотами. Это упростит запросы. И PHP-код для создания страницы календаря будет намного проще: вам нужно просто выполнить iteract над результирующим набором. И чтобы получить хорошую производительность, вы должны создать подходящий индекс и ключ (я не могу заранее предложить их).
ИЗМЕНИТЬ ДОБАВИТЬ ПРЕДЛОЖЕНИЕ:
@pixeline: Поскольку вы не добавляли макеты таблиц, это стрелять в темноте, я думаю, просто изменив INNER JOIN
на LEFT OUTER JOIN
, вы это сделаете:
SELECT DISTINCT date, hour_from, hour_to, courses.description, courses.alias, teachers.name, locations.new_acronym
FROM timetables
LEFT OUTER JOIN courses ON (courses.id=timetables.course_id)
LEFT OUTER JOIN teachers ON (teachers.id=timetables.prof_id)
LEFT OUTER JOIN locations ON (locations.id=timetables.location_id)
WHERE ((timetables.prof_id='$id')
AND (timetables.date >= '$starting_date')
AND (timetables.date < date_add('$starting_date', INTERVAL 7 day))) ;
Если timetables
не имеет всех часов для дня, вы можете создать таблицу с ними (скажем timeslot
) и поместить ее в первую таблицу и поместить расписания в качестве LEFT OUTER JOIN
или CROSS JOIN
. А остальные как LEFT OUTER JOIN
, как указано выше.
Я сделал что-то подобное, и я думаю, что таблица с 7 столбцами и 11 строками - очень плохое решение - возможно, но плохо.
Только одна таблица, где вы храните все "события", а затем визуализируете это с помощью php. Вы Calender WAY более гибкие (представьте, что вы хотите добавить больше часов в день или сделать так, чтобы можно было использовать полчаса, если вы построите это нормально, это будут только настройки конфигурации).
Если вы все еще выбираете вариант 1: Я не думаю, что он очень ресурсоемкий, и я думаю, что вы можете кэшировать этот материал, чтобы он не был жестким.