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

[twist]

Одержим идеей создания своей биржи ставок. При проектировании системы столкнулся с непреодолимой проблемой. Собственно самой архитектурой данных в момент заключения пари. В отличии от букмекерской конторы, в которой как в магазине есть товар (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  |
----------------------------
Игрок Б |      |      |
        |      |      |
----------------------------

И вот как эти данные а самое главное движение этих данных должны хранится, вопрос для меня остается открытым.

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

 

[Black Hat]

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

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