Архитектура данных биржи ставок в момент заключения пари

Тема в разделе "Базы данных", создана пользователем twist, 31 мар 2017.

Модераторы: latteo
  1. twist

    twist Создатель

    Регистр.:
    16 мар 2007
    Сообщения:
    40
    Симпатии:
    2
    Одержим идеей создания своей биржи ставок. При проектировании системы столкнулся с непреодолимой проблемой. Собственно самой архитектурой данных в момент заключения пари. В отличии от букмекерской конторы, в которой как в магазине есть товар (kf) который покупают (bet), здесь каждый исход в двойном размере back/lay, так и еще весь рынок должен по всей видимости фиксироваться в двух местах в matched и unmatched.

    Есть конечно затыка в организации самих рынков (тотал, победитель, фора), но это на данном этапе не важно.

    Для примера возьмем теннисный матч

    Игрок А играет с Игроком Б

    существует два исхода Победа А и Победа Б, из чего следует четыре варианта пари за/против_Победа_А и за/против_Победа_Б
    По сути конечно За_Победа_А практически равно Против_Победа_Б без всяких исключений, но с оглядкой на законодателей моды (betfair, betdaq) эти пари принимаются отдельно

    Далее сымитируем варианты развития событий, для наглядной демонстрации ситуации

    Иван решил поставить $2 на За_Победа_А и верит что шансы примерно равны, тем самым его вполне устроит коэффициент 1,9
    Его ставка должна быть помечена как unmatched, и для наглядности отображена на сайте в колонке Против для поиска оппонента в пари.
    Но для правильного расчета обязательства его предложение будет отображено как 2,11 (видимо kf для lay ставки должен расчитываться и тоже хранится вместе со ставкой)
    Код:
                За  Против
    ----------------------------
    Игрок А |      | 2.11 |
            |      |  $2  |
    ----------------------------
    Игрок Б |      |      |
            |      |      |
    ----------------------------
    
    Андрей не верит в победу Игрока А и решает ставить Против, но его не устраивает предложение Ивана, он верит что может получить больше. В итоге
    его ставка: желает выиграть $5 при kf 1,95 рискует $4,75. Вполне логично что она тоже помечена как непарная. (и здесь должен отмечен kf для back ставки)
    Код:
                За  Против
    ----------------------------
    Игрок А | 2.05 | 2.11 |
            |  $5  |  $2  |
    ----------------------------
    Игрок Б |      |      |
            |      |      |
    ----------------------------
    
    Сергей видит предложение Андрея и решается вступить с ним в пари, но желает поставить $8
    Тем самым ставка Андрея становится парной а $3 доллара Сергея помечаются как непарная_ставка и переносятся в колонку Против
    Код:
                За  Против
    ----------------------------
    Игрок А |      | 1.95 | 2.11 |
            |      |  $3  |  $2  |
    ----------------------------
    Игрок Б |      |      |
            |      |      |
    ----------------------------
    
    Ну и последний вариант исхода почти как в магазине. Михаила устраивает предложение Сергея, и он в полном объеме заключает с ним пари. Ставка и Михаила и Сергея становится парной в полном объеме
    Код:
                За  Против
    ----------------------------
    Игрок А |      | 2.11 |
            |      |  $2  |
    ----------------------------
    Игрок Б |      |      |
            |      |      |
    ----------------------------
    
    И вот как эти данные а самое главное движение этих данных должны хранится, вопрос для меня остается открытым.

    Прошу помощи/совета.
     
  2. Black Hat

    Black Hat

    Регистр.:
    15 май 2015
    Сообщения:
    155
    Симпатии:
    101
    Отвечаю за себя, но может и за многих. Очень трудно понять что-то, если не владеть терминологией. Схемы ничем особо не помогают. Но смысл уловил.
    Таблицы
    1. users Пользователи
    2. rate Ставка с привязкой к пользователю - там где "вся ставка"
    3. bet "Частичные ставки" - наполняются по данным "всей ставки" с привязкой к двум пользователям
    4. free_bet "Неудовлетворенный остаток" с привязкой к пользователю
    Таблицы 3-4 хранят денормализованные данные, поэтому их обработку лучше обернуть в транзакцию или сделать хранимую процедуру и перетащить бизнес-логику в нее.
    Я бы сделал как-то так.

    PS. Ну и хранимки такие
    Создать ставку(пользователь, сумма, ...)
    Ответить на ставку(ID ставки, пользователь, сумма)
    Отказаться от ставки(ID ставки, пользователь)
     
    Последнее редактирование: 31 мар 2017