такая задача может существовать исключительно как результат неудачного архитектурного решения, в частности неудачного выбора хранилища данных.
Но сути дела не меняет даже если возмете какой нибудь redis - все так или иначе сведется к арифметическим действиям не более того. Хотя непонятно почему нельзя держать какую то переменную в памяти или той же БД и доумножать ееп сразу при добавлении записи. как бы там ни было математика о которой топик тут никаким боком.
задача была действительно задрочкой на математику без практического использования, т.к. перемножать данные в бд оптом и постоянно никому не надо, но вот букмекерский бизнес работает по математике и теории вероятности и все процессы надо автоматизировать, чтобы заменить букмекера
чтобы уверить тебя что ошибки архитектурного решения нет я объясню подробнее, игрок ставит ставку на коэффициент, то число на которое умножатся его деньги в случае выигрыша, когда ставка сама по себе все просто, но если игрок считает что произойдут несколько определенных событий и ставит на то что все они без исключения произойдут, то у него вероятность на проигрыш растет, а сумма выигрыша остается таже если ничего не делать, чтобы выровнять вероятность коэффициенты его ставок перемножаются
как следствие у тебя таблица ставок, в которой много специфических полей, про которые я рассказывать, т.к. они не играют тут роли, не буду и поле с коэффициентом, на который он поставил, часть ставок может быть отменена и общий перемноженный коэффициент надо считать
сразу предугадывая возражение скажу, то сделать поле с общим коэффициентом и потом делить на выбывший коэффициент нельзя, специфика не позволяет, игрок может поставить на автоматически генерируемую цепочку события, в которой будут участвовать вероятные 20! вариация ставок
пересчитывать циклом не вариант, передавать все в более гибкую среду и считать там тоже, решение сугубо математическое, в лоб решить нельзя не получится вписаться в отведенное время
