2012-06-16 2 views
3

Я строю сайт для небольшой коллекции родителей в частном детском саду. Одна из желаемых функций сайта - иметь календарь, в котором вы можете выбрать, в какие дни вы можете нести ответственность за очистку локалей. Теперь я создал рабочий календарь. Я нашел простой скрипт онлайн, который я изменил, чтобы соответствовать нашей цели. Технически это работает хорошо, но я начинаю задаваться вопросом, действительно ли мне нужно изменить способ извлечения информации из базы данных.Слишком много вызовов SQL при загрузке страницы?

Календарь представлен ежемесячно и рисуется как таблица с использованием цикла for. Это означает, что указанный цикл for-loop запускается 28-31 раза каждый раз, когда страница загружается в зависимости от месяца. Чтобы представить, кто несет ответственность за очистку каждый день, я добавил вызов в базу данных MySQL, где хранится день очистки каждого члена. Псевдокод выглядит следующим образом, упрощается:

Draw table month 
    for day=start_of_month to day=end_ofmonth 
     type day 
     select member from cleaning_schedule where picked_day=day 
     type member 

Это означает, что каждая перезагрузка страницы делает по крайней мере 28 ВЫБРАТЬ вызовы в базу данных и мне кажется неэффективной, и что один может быть восприимчив к DDOS- атака. Есть ли более эффективный способ получить тот же результат? Там гораздо более сложные календари бронирования, как они справляются с этим?

ответ

5
SELECT picked_day, member FROM cleaning_schedule WHERE picked_day BETWEEN '2012-05-01' AND '2012-05-31' ORDER BY picked_day ASC 

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

2

Кэш запросов MySQL сохранит ваш бекон.

Краткая версия: Если вы повторяете тот же SQL-запрос часто, он будет обслуживаться без доступа к таблице, если базовые таблицы не изменились. Итак: первый звонок в течение месяца будет ок. 35 SQL-запросов, которые много, но не слишком много. Второй загрузчик одной и той же страницы вернет результаты, быстро сбрасываемые из кеша.

В моем опыте говорится, что это, как правило, намного быстрее, чем создание фантастических запросов присоединения, даже если это было бы возможно.

+0

Но если кеш, скажем, июнь, а затем я перехожу на июль, он должен снова сделать весь shebang, но я получаю ваш дрейф. – Sandokan

+0

В кэше запросов может быть более одного (по сути: много) запросов - см. Документы MySQL .. о, дерьмо, они прямо сейчас! –

+0

Опираясь на MySQL для кэширования ваших данных, как правило, не является хорошей практикой. –

1

В SQL можно использовать все больше и меньше. Таким образом, вместо того, чтобы делать один выбор в день, вы можете написать один выбрать в течение всего месяца:

SELECT day, member FROM cleaning_schedule 
WHERE day >= :first_day_of_month AND day >= :last_day_of_month 
ORDER BY day; 

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

В зависимости от структуры данных, следующий оператор может быть возможным и более удобно:

SELECT day, group_concat(member) FROM cleaning_schedule 
WHERE day >= :first_day_of_month AND day >= :last_day_of_month 
GROUP BY day 
ORDER BY day; 
+0

Чтобы ваш второй пример работал, вам понадобится явный день GROUP BY в вашем запросе, иначе он будет выровнять все результаты до одной строки с большим количеством членов –

1

28 запросов разве массовый выпуск и довольно общие для большинства коммерческих веб-сайтов, но рекомендуем только захватывая ежемесячные данные по каждому месяц на один удар. Затем прокручивайте записи каждый день.

2

Не то, чтобы 28 звонков это большое дело, но я бы воспользовался объединением и вызовом в течение всего месяца данных за один удар. Затем вы можете перебирать результат MySQL Query, как если бы это был массив.

Смежные вопросы