Устраиваем розыгрыш.
По условиям розыгрыша , после выполнения основного задания участнику даётся 1 лотерейный билет.
В базе данных генерируется id_лотерейного_билета и этот id связывается с id_участника_розыгрыша.
При розыгрыше - ставим рандом от цифры 1 до цифры крайнего id_лотерейного_билета
И таким образом мы понимаем кто выиграл приз.
За каждого приглашённого человека по реф ссылке в розыгрыш, участник розыгрыша получает столько же лотерейных билетов сколько у него есть на данный момент.
1билет Х2 итого 2 билета, потом за каждого нового приглашённого реферала участнику будет прилетать 2,4,8,16,32 и тд
Но есть проблема!
Когда участник розыгрыша пригласит 21-го человека - он получит 1.048.576 лотерейных билетов.
Это в базу данных нужно сгенерировать и записать 1млн строк в формате:
id_лотерейного_билета
id_участника_розыгрыша
собственно вопрос, как высчитать сколько данная операция будет потреблять ресурсов?
что б потом можно было понять сколько нужно будет времени на том или ином железе для выполнения данной операции.
возможно я вообще не в том направлении думаю и есть какие-то другие решения как это можно сделать)
_____________________________________
по поводу убрать х2, и добавить фиксированную "награду" - это можно, но это убьет мотивацию участников приглашать друзей. так как с каждым приглашением растут ставки и растет азарт.
тут есть масса вариаций как это можно изменить... к примеру, оставить Х2 до определенного значения, или давать на 10 билетов больше чем в прошлый раз...
но главный вопрос как же можно просчитать нагрузку по ресурсам)
Для правильного вопроса надо знать половину ответа
Шанс выигрыша определяется не номерами билетов, а исключительно их количеством. Так что никакого смысла генерировать и хранить номера нет. Достаточно добавлять нужное количество билетов пользователю.
это возможно, если человек не видит номера лотерейного билета, но тогда это не лотерейный билет
игроки не поверят в то что все по честному, если у них на руках не будет чего то 'материального' (даже если это число, его можно посмотреть сегодня и завтра оно останется тем же)
p.s. я знаю что все не по честному, я говорю про веру игроков в честность
не совсем так
рандом на то он и рандом , что он из 100млн вариантов может выбрать второй
я провел более 1000 розыгрышей
и по опыту могу сказать, что часто в Инстаграм выигрывали люди которые написали 1 коммент, а не 200-300
по аналогии: 1 коммент = 1 лотерейный билет
так же могут быть десятки людей в топе с одинаковым количеством билетов
pasha0011, Если розыгрыш честный, то именно так.
Пусть в игре миллион билетов. У вас всего один. Ваш шанс на выигрыш - одна миллионная. И неважно, какой у вас номер билета, шанс не поменяется. Если же у вас 500000 билетов, то ваш шанс - 1/2. И опять таки, абсолютно не важно, какие именно номера у этих билетов.
ну тогда если вопроса про веру не стоит то вариант Rsa97 отличный, можно так и говорить - каждый новый приглашенный участник повышает ваши щансы вот на столько то
pasha0011, Представьте простую ситуацию. Вместо билетов - шары с именем игрока. Каждый купленный/полученный билет просто добавляет один шар в барабан.
При розыгрыше мы вслепую достаём один шар из барабана и читаем имя. Наличие или отсутствие номеров на этих шарах ничего не изменит.
номер лотерейного билета можно выдавать каким-либо детерминированным алгоритмом, формирующим номер по его позиции
тогда у пользователя можно хранить номера билетов интервалами (выданы билеты с номерами a+n...a+n*2), сам же список лотерейных билетов не обязательно хранить в базе данных
на время раздачи крутится сервис, раздающий последовательно номера (интервалами) пусть даже для этого тратит память, какой-нибудь полурекурсивный алгоритм перестановки, собственно это и есть вопрос, как его красиво реализовать
записывать же в базу данных 2^100500 чисел - неразумная трата ресурсов.
Простой
