Порядок выполнения в Update
 

Допустим есть такой запрос:

UPDATE table_name SET avg = avg * count/(count + 1) + :newValue / (count + 1), count = count + 1 WHERE id = :id

Сработает ли такой запрос правильно или он может сначала посчитать count, а потом avg? Если он срабатывает правильно, то похоже у меня накапливается ошибка вычислений с вещественными числами в среднем значении...

Ответ: Порядок выполнения в Update
 

Сделал тест, SET выполняются по очереди (слева на право).
Странная у тебя там формула Average. Но ты можешь использовать ROUND(X, D) где D - степень точности для округления, например если D=2, то ROUND(0.0165, 2) == 0.02

А вообще лучше избегать любые "накопительные" операции с float числами где только возможно. Лучше пересчитать, чем накапливать.

Ответ: Порядок выполнения в Update
 

А есть другие варианты?

Я не храню инфу о всех элементах последовательности для среднего, поэтому исходя из текущего среднего и количества элементов мне надо получить новое добавляя новый элемент.

UPD: вероятно есть вариант использовать N последних чисел в последовательности. Например если N = 100, то будет примерно так:

UPDATE table_name SET avg = avg * (99/100) + :newValue / 100 WHERE id = :id

И не хранить count в таблице...

Ответ: Порядок выполнения в Update
 

А сколько примерно будет записей для просчета общего? 10, 100, 1000?
Т.к. в SQL есть SUM, делать это каждый раз - может быть тяжеловато если слишком много записей, или если эта query часто выполняется.

Ответ: Порядок выполнения в Update
 

Фактически это среднее время трассы, т.е. каждый финиш игроков на трассе будет фиксироваться. Я думаю будет не мене десятков тысяч

Ответ: Порядок выполнения в Update
 

если каждое время фиксируется в базе, то не проще ли сначала посчитать сумму этого времени, а потом поделить ее на число записей в базе?

Ответ: Порядок выполнения в Update
 

HolyDel именно. Тем более статистика "сколько времени откатался" тоже приятная, и всего-то поделить на число раундов, и вот вам среднее.

Ответ: Порядок выполнения в Update
 

Я наверное не так выразился, каждое время в плане среднего времени, если сохранять в базе все финиши игроков на трассах, та это просто ппц объемы будут.
К примеру 10 игроков, до финиша можно доехать за 30 секунд, заезд 20 минут. Т.е. в худшем случае на 10 игроков за заезд будет 400 финишей. И это только одна игра. А если будет одновременно играть несколько тысяч игроков (сотни заездов)?

Сейчас я сохраняю лучшее время игрока на трассе и лучшее время трассы. Нужно среднее время трассы для расчета бонусов и рейтинга.

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

Ответ: Порядок выполнения в Update
 

В UNSIGNED BIGINT вмещается 18446744073709551615 ужасно много (599,730,287,456 лет), так что не беспокойся, вместится.

Ответ: Порядок выполнения в Update
 

вопще давать бонусы за среднее время карты, которое рассчитывается динамически от действий игроков, имхо, некорректно.

у тебя появятся 100500 твинков, которые будут спецом ехать медленно, чтобы мейны поулчали бонусы за проезд. тебе это надо? проедь трассу сам с рядом знакомых, посмотри ее время - оно пусть и будет бонусным.
если увидишь что бонусы падают слишком часто - уменьшаешь время на 3 секунды, слишком редко - увеличиваешь.

Ответ: Порядок выполнения в Update
 

а лучше бонус если время лучше чем у 95% игроков (или другой процент)

Ответ: Порядок выполнения в Update
 

Угу, бонус от статистического. Таким образом все могут получить бонус за хорошую езду, и будет честно - только лучшие.
Естественно нужен также бонус за 1/2/3 место, но это другое.

Ответ: Порядок выполнения в Update
 

Уговорили, сделаю сумму времени в int64, а по поводу подсчета бонусов еще не решено все. Мне сейчас нужны данные, которые я смогу как-то использовать потом. Баланс довольно сложно придумать в заездах, где будут участвовать разные машины (по скорости и управляемости). Возможно все еще не один раз поменяется...