Akina, ну да, я смотрю на ситуацию с точки зрения похапешника, которому свалилась довольно обычная задача: разобраться, что не так с вот этим незнакомым сайтом.
Akina, если пых-скрипты все равно выполняются по крону, не вижу смысла усложнять работу сайта (например, для того, кто в ней будет разбираться) разнесением таких действий по крону и БД. Даже если БД может сделать что-то эффективнее.
Овчинка, выделка и все-все-все.
И предполагаете ее всю, со всем барахлом, которое ей может понадобиться лишь однажды, утаптывать в один исполняемый файл? Для этого существуют инсталляторы, которые разбросают это барахло по папкам программы, откуда она, буде понадобится, скопирует это в папки пользователя.
Akina, тут еще большой вопрос, что именно включает в себя процедура раздачи призов.
Если обращение к API кассы, например, то планировщик БД как бы мимо ;)
KarambyG, такие вещи не делаются по-простому: о, надо раздать призы, начинаем раздавать. Потому что если не управиться за минуту, крон снова запустит скрипт, и он снова скажет "о, надо раздавать призы".
Надо создать задачу и, когда она пошла на обработку, отметить это. Чтобы следующий скрипт увидел, что заново создавать и обрабатывать задачу не следует, даже если первый почему-то призадумался. А если задача уже час на обработке, но все еще не отмечена, как выполненная - хорошо бы сообщить вебмастеру, что что-то пошло не так...
Очередь задач это называется.
KarambyG, я плохо отношусь к энтропии. Запланированные в вопросе действия бессмысленны. Вот всплывшие по ходу обсуждения призы - да, могут оправдывать действия по расписанию. Только скорее не отдельный скрипт конкретно под эту задачу, а очередь обработки с механизмом исключения задвоения исполняемых задач.
KarambyG, а что, при подведении итогов никто еще не следит за fair play и не гоняет читеров?
Ну, этот обработчик можно повесить на крон. Если, конечно, призы не таковы, что до первого зашедшего за призом их можно и не обрабатывать.
KarambyG, подозреваю, для формирования главной страницы этот список читается из базы. При этом достаточно двух полей - начала турнира (заполняется при создании) и конец (заполняется при завершении), чтобы по ним и текущему времени определить его статус. Более того - если требуется, менять этот статус прямо на странице, отслеживая текущее время js-скриптом.
KarambyG, это понятно, что вы считаете это нужным. Я предложил подумать - зачем.
Когда реально понадобится статус турнира - он легко определяется. На кой хрен для этого теребить базу каждую минуту?
Лучше расскажите, зачем вам "чтобы постоянный селект".
Чтобы определить статус турнира, достаточно два поля-таймштампа: начало и конец.
Причем определяться это будет, когда понадобится, а не разводя энтропию.
Stalker_RED, Сергей delphinpro, окей, я, видимо, уже не могу адекватно оценивать простоту для новичков-подоконников. Для меня "просто" - это "легко гуглится", "один текстовый файл настроек" и "несколько банальных команд". А сложно - это скакать по галочкам на вкладочках и искать в тоннах воды информацию о том, как оно вообще должно работать.
Однако напомню: усилия, затраченные новичком на освоение Докера, пойдут в портфолио, а вот пыхтение над Опенсерверами и ХАМРами - в корзину.
Кстати, необязательно досконально разбираться с Докером, чтобы взять его и использовать. Есть Laradock, например (см. логин ТС) ;)
Stalker_RED, полагаете, ему сбросили проект в этом подоконном кадавре?
Для проекта на пыхе нужен LAMP, сейчас самый простой и распространенный стек, который это обеспечивает - таки Докер.
Вообще-то это больше похоже на битую память, чем на несовместимость.