Автоматическое обновление таблицы MYSQL по дате

Question

Автоматическое обновление таблицы MYSQL по дате

0

У меня есть таблица MYSQL, содержащая информацию о событиях. Мне нужен механизм, который обновляет статус каждого события в соответствии с его датой ( "более", если это минута). Каков лучший способ сделать такое? Обновить статус события, когда любой пользователь входит в систему (бесполезная процедура для большинства пользователей), создать какую-то внутреннюю задачу (например, задание cron?) Или любым другим способом. Прямо сейчас статус события обновляется только тогда, когда автор регистрируется. Это работает, но другой пользователь увидит событие как "запланированное" до тех пор, пока автор не войдет в систему, даже если дата прошла. Я использую PHP кстати. Благодаря

JoaoPedro 28 сен. 2010, в 16:30

Источник

1

обновить его, когда событие запрашивается.
Your Common Sense 28 сен. 2010, в 13:48
2

Дата является единственным критерием? Тогда зачем вам что-то обновлять? Вместо этого используйте некоторую арифметику даты, например, сравнивая значение даты с now ().
VolkerK 28 сен. 2010, в 15:27
0

Это хороший момент, но приложение в значительной степени зависит от состояния событий, поэтому постоянное сравнение дат - не вариант. Это имело бы смысл, если бы статус запрашивался только несколько раз. Обновление по запросу является опцией. Я благодарю вас обоих.
JoaoPedro 28 сен. 2010, в 15:52

Показать ещё 1 комментарий

Теги:

php

mysql

modeling

5 ответов

0

Каждый ответ принимает вашу причину для ОБНОВЛЕНИЯ. Однако позвольте мне подвергнуть сомнению это решение с расширением предложения Col.Srapnel от комментариев.

Обновление можно рассматривать как пустую трату ресурсов, так как вы можете рассчитать ее на ходу с сопоставлением даты памяти (что на несколько порядков быстрее, чем ввод-вывод для хранения).

Существует два подхода к этому:

query/view может это сделать (и стоимость действительно должна быть небрежной)
на самом деле делает это на стороне php после получения результатов (рассмотрим задачу форматирования/презентации)
это может быть сделано даже на стороне клиента, что, если возможно, было бы лучшим решением (это может привести к проблемам обслуживания/безопасности).

Конечно, могут быть веские причины игнорировать эти решения, но я считаю, что производительность сама по себе недостаточна (большинство БД связаны с I/O).

Unreason 31 янв. 2011, в 13:17

0

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

Jaydee 28 сен. 2010, в 18:07

0

Обновление при входе пользователя в систему - это не очень хорошая идея, поскольку она добавляет слишком много давления (если есть много пользователей). Лучший способ сделать это - запустить cronjob каждую ночь после 12 часов утра или в начале дня. Если вы все еще хотите сохранить свой старый код, а затем оберните его кодом даты. псевдо будет выглядеть так:

$updated_last = last modification time of the file "updated";
if($updated_last is more than 1 day) {
 update db; (your old code)
 touch file "updated";
}

tanjir 28 сен. 2010, в 15:15

0

Я полагал, что задание cron не сделает этого, так как статус события может быть запрошен и изменен на «более» через несколько часов после создания события. Спасибо хоть
JoaoPedro 28 сен. 2010, в 23:18
0

@JoaoPedro "статус события может быть запрошен и изменен на" более "через несколько часов после создания события". Это не правильная операция? Если статус основан на дате, статус меняется в полночь или я что-то упустил?
Jaydee 29 сен. 2010, в 08:15

0

Используйте это,

UPDATE events SET status = 'over' WHERE DATE(event_date) > NOW();

Запускайте его каждый день, один раз в день, cron.

xmarcos 28 сен. 2010, в 14:42

Ещё вопросы

обновить его, когда событие запрашивается.
Дата является единственным критерием? Тогда зачем вам что-то обновлять? Вместо этого используйте некоторую арифметику даты, например, сравнивая значение даты с now ().
Это хороший момент, но приложение в значительной степени зависит от состояния событий, поэтому постоянное сравнение дат - не вариант. Это имело бы смысл, если бы статус запрашивался только несколько раз. Обновление по запросу является опцией. Я благодарю вас обоих.
Я полагал, что задание cron не сделает этого, так как статус события может быть запрошен и изменен на «более» через несколько часов после создания события. Спасибо хоть
@JoaoPedro "статус события может быть запрошен и изменен на" более "через несколько часов после создания события". Это не правильная операция? Если статус основан на дате, статус меняется в полночь или я что-то упустил?

stevendesu · Accepted Answer · 2010-09-28T14-39-00.000Z

Я бы рекомендовал обновить статус в любое время, когда запрашивается статус. Или еще лучше, даже не сохраняйте статус в базе данных вообще, а просто вычисляйте его каждый раз, когда он запрашивается на основе других переменных. Таким образом, всякий раз, когда у вас есть список таблиц, статус или кто-то запрашивает статус, просто введите дату события, сравните его с сегодняшней датой и отправьте им "не запущено", "текущее" или "за".

Если вам, конечно, не нужны более возможные статусы ( "планирование", "подготовка", "настройка" и т.д.). Затем вам понадобятся либо запланированные даты/время для каждого из этих статусов, либо вам нужно будет сохранить переменную статуса. В любом случае, вы могли бы обновить статус (согласно сегодняшней дате и любой другой соответствующей информации) в то время, которое оно запросило.

Обновление по запросу, безусловно, путь. Не сохранение статуса в базе данных сделает все более сложным. Перечисление прошлых событий является обычной задачей в приложении, и каждый раз, когда запрашивается список, потребуется много обработки. Слишком много вещей, в зависимости от состояния событий. Спасибо хоть.
@JoaoPedro, тот факт, что «слишком много материала» зависит от состояния события, не обязательно оправдывает хранение дополнительных данных в БД - фактически наоборот; большинство систем БД привязаны к вводу / выводу, что означает, что они ожидают, пока данные будут считаны / записаны в хранилище и из него, и добавление лишнего ненужного и чрезвычайно дешевого вычисляемого столбца в смесь обычно замедляет (!) систему. Не слишком много для одного поля (плюс индекс), но если оно используется как принцип, то оно складывается.