Как лучше плавно увеличивать значение?

Question

[Оптимус Пьян]

Допустим у нас обычные php и mysql
Значение населения 100 человек. Параметр счастья был 0, построили памятник Ленину он стал 20
Вопрос: как лучше плавно увеличивать счастье населения с 0 до 20?
Идея которая пришла сходу это обход каждую минуту по крону и смотреть например
if(текущее счастье < максимума счастья) { увеличить текущее на 1 }
И так до тех пор пока текущее не станет 20. Но если в БД много пользователей и у каждого есть такой параметр или несколько, рационален ли этот метод?
P.S. Есть ещё решения когда параметр увеличивается не линейно, но тут особо нет идей, например:
0-5 - 3 ед. в час
5-10 - 2 ед. в час
10-15 - 1 ед. в час
15-20 - 0,5 ед. в час

Comments

[Назар Мокринский]

> построили памятник Ленину он стал 20
Epic fail...

[Оптимус Пьян]

Назар Мокринский: ну вы в Tropico не играли вероятно? )))

[Назар Мокринский]

Дмитрий: Нет, но видел как играли, суть понимаю

Answer 1

[Curly Brace]

установить timestamp после постройки памятника.
когда кто то запрашивает конкретное значение, плюсовать его в зависимости от timestamp
соответственно это требует что бы объект игровой представлял собой не просто набор параметров, а так же имел в себе логику работы в виде функций, которые "умно" получают и устанавливают значения

Comments

[Оптимус Пьян]

Это вы про случай нелинейного увеличения значения?

[Макс]

Дмитрий: да без разницы. В описаном Curly Brace варианте триггером изменения параметра будет обращение на чтение. Т.е. в случае, если никто эту величину не читает - то изменение происходить не будет. А вот когда "прочитают" - обновится сразу на величину, зависящую от прошедшего времени.
Избежите "лишних" обновлений, и рост будет максимально плавным. С другой стороны, если читают часто - достаточно много накладных расходов получится.

[Оптимус Пьян]

Макс: А понял вроде, спс. Тут ещё фишка в том что от счастья например налоги могу зависеть. Построили вечером, первый раз запросили утром, итого всю ночь налоги (потому что параметр не запрошен т.е. 0) не начислялись, а должны были по идее...

[Макс]

Дмитрий: нет, не так - функция расчета налогов запросит величину счастья, что вызовет перерасчет счастья. Почему я и говорил о частоте чтения - если читают слишком часто, то это получится "дорого" с точки зрения БД.

[Оптимус Пьян]

Макс: понял, спасибо, думал может кто-то скажет "есть другой путь" типа триггеров, или может лучше key-value какое-то подключить или redis или типа того...

[Макс]

Дмитрий: триггер - это реакция на изменения в таблице. Что-то должно запустить этот триггер.
По сути сейчас мы видим 2 пути решения задачи обновления параметров - по таймеру и по событию.
ИМХО, по таймеру в Вашем случае может получиться удобнее. Для каждого из параметров установите время следующего изменения, далее по крону дергайте процедуру, которая сравнит текущее время с планируемым и заапдейтит эти параметры при достижении времени. Если там-же хранить и величину изменения - то на всю таблицу хватит 1 UPDATE.

Answer 2

[profesor08]

Ну раз все данные в БД, то пусть этим занимается sql сервер.
Сделайте UPDATE по определенным условиям, а sql сервер все сделает.

$db->query("UPDATE users SET happiness = happiness + 1 WHERE happiness >= 10 AND happiness < 15");
$db->query("UPDATE users SET happiness = happiness + 3 WHERE happiness >= 0 AND happiness < 5");

Ну это так, совсем по простому.

Еще можете сделать процедуру в базе данных, которая все будет делать. И лишь вызывать ее из скрипта.