У нас есть много действий, которые игроки могут предпринять в игре. Представьте себе карточную игру (например, покер) или настольную игру, в которой на каждом этапе принятия решения имеется несколько вариантов действий и существует четкая последовательность событий. Мы отслеживаем каждое действие, предпринимаемое игроком. Мы заботимся о размере действия (если применимо), других возможностях действия, которые не были предприняты, игроке, который принял действие, действии, с которым игрок столкнулся перед своим ходом. Кроме того, нам нужно знать, произошло ли какое-либо действие или не произошло до того, как мы рассмотрим действие.
База данных помогает нам ответить на такие вопросы, как:
1. Как часто выполняется действие A с учетом возможность? (сумма (actionA) / sum (actionA_opp)
2. Как часто действие A выполняется с учетом возможности и при условии, что действие B имело место?
3. Как часто действие A выполняется с размером X или выполняется в пределах Y секунд при наличии возможности и при условии, что действие B имело место, а действие C не выполнялось?
4. Как часто выполняется действие A, если действие B имело место у игрока P?
Так что для Для каждого действия нам нужно хранить информацию об игроке, который выполнил действие, размере, времени, выполненном действии, доступных возможностях действия и других характеристиках. Количество действий ограничено.
Одна игра может в среднем 6 действий, а некоторые - до 15.
Может быть миллион игр, и мы хотим, чтобы совокупные запросы по всем из них выполнялись максимально быстро. (секунды)
Это может быть представлены в базе данных документов с массивом встроенных документов, таких как:
game: 123
actions: [
{
player: Player1,
action: deals,
time: 0.69,
deal_opp: 1
discard_opp: 1
},
{
player: Player2,
action: discards,
time: 1.21
deal_opp: 0,
discard_opp: 1,
}
...
]
или в реляционной модели:
game | player | seq_n | action | time | deal_opp | discard_opp
123 | Player | 1 | deals | 0.28 | 1 | 1
Все возможно проекты, которые я придумываю, не могут удовлетворить все мои условия. В представленной реляционной модели для просмотра предыдущих действий, предпринятых в той же игре, требуется N внутренних соединений, где N - предыдущие действия, для которых мы хотим выполнить фильтрацию. Учитывая, что таблица будет содержать миллиарды строк, потребуется несколько самостоятельных объединений в таблице миллиардов строк, что кажется очень неэффективным.
Если мы вместо этого сохраним ее в широкой таблице столбцов и представим всю последовательность в одном строка, у нас есть очень простые агрегаты (можно отфильтровать то, что произошло, а что нет, сравнив значения столбцов, например, sum (deal) / sum (deal_opp), где deal_opp = 1, чтобы получить частоту действия сделки, если у игрока была возможность сделать это) ) но мы не знаем, ВОЗ предприняла данное действие, которое является необходимостью. Мы не можем просто добавить столбец игрока рядом с действием, чтобы указать, кто совершил это действие, потому что такое действие, как колл или сброс, или может иметь много игроков подряд (в покерной игре один игрок рейзит, 1 или более игроков могут сделать колл).
Больше возможностей:
- База данных графиков (избыточно, если у нас есть не более 1 другого связующего узла? - в основном, связанный список)
- Закрытие таблиц (более эффективно запрос предыдущих действий)
- ??