2012-02-27 2 views
0

Я новичок в RavenDB, и я все еще пытаюсь найти оптимальный способ моделирования данных для текущего сценария. Вот как выглядят данные.Как смоделировать статистику футбольных матчей в RavenDB

Game 
- Teams 
    - Team 1 
    - list of players 
    - Team 2 
    - list of players 
- Events 
    - Event 1 
    - type: Pass 
    - teamId 
    - PlayerId 
    - Event 2 
    - type: Goal 
    - teamId 
    - PlayerId 

В начале каждой игры мы получаем общую информацию для игры (например, команды и т.д.) Места и затем через каждые несколько минут мы получаем обновленный список событий. Кроме того, мне нужно иметь возможность запрашивать данные для определенного игрока, играющего в игру (например, сколько проходит у игрока)

Хранить ли это как отдельный документ? Разделение событий на отдельный документ, например. GameEvents? Есть ли третий сценарий?

ответ

1

Храните его как отдельный объект - структура, которую вы определили, великолепна. Затем просто определите индексы для различных типов запросов, которые вы будете делать. Не разбить вещи на таблицы с отношениями - это то, что делает документы DB, такие как Raven awesome - отлично подходит для сценариев, как то, что вы описываете.

+0

Если вы идете с помощью этого метода, для * большинства * вашей статистики вам будет лучше загружать весь документ (который представляет 1 игру), обрабатывая его в памяти, а затем записывая обратно в документ. Для статистики, которая находится в нескольких играх, вы можете посмотреть в Map/Reduce –

+0

Мэтт, который звучит как хорошая идея. Чтобы быть ясным, если я хочу рассчитать проходы для игрока, я бы загрузил игровой документ, выполнил вычисления и сохранил его снова. – marto

+0

@Matro, да, это идея, хотя для этого много накладных расходов, поэтому Patching может помочь вам. http://ravendb.net/docs/client-api/partial-document-updates –

3

Я бы не стал беспокоиться о том, как это будет храниться в RavenDB. Это красота баз данных документов; не думайте реляционно. Создайте свою модель домена объектно-ориентированным способом, чтобы она была создана (команда имела бы список <Player> и т. Д.), А затем просто сохраняйте объекты по мере необходимости.

Я имел в виду блог о том, как я сохранил свою модель домена при использовании RavenDB. Мне нужно опубликовать это ...

** EDIT ** Я наконец опубликовал этот блог: http://bit.ly/xUsYJK. Это показывает, как Presto сохраняла несколько чистую модель домена при использовании RavenDB.

Кстати, Daniel Lang имеет хороший блог по этой теме:

http://daniellang.net/how-to-handle-relations-in-ravendb/

Я использую Включать <T> подход, потому что я хотел, чтобы мои объекты домена ссылки друг на друга в чем я рассмотрите соответствующий путь.

У Даниэля также есть раздел «Денормализовать ваши рекомендации». Некоторые люди предпочитают этот метод.

1

Думая о том, сколько таких событий может произойти во время игры, я считаю, что вы определенно хотите иметь их как отдельные документы. Таким образом, вам не нужно загружать и обновлять игровой документ при каждом входящем событии, поскольку это также будет довольно дорого, если документы будут очень большими.

Чтобы получить статистику по всем событиям игры, я бы предпочел иметь некоторые индексы, которые собирают соответствующие данные.

+0

Это была моя оригинальная мысль. Игровой документ с событиями может вырасти примерно до 1 МБ.Если я отделяю события примерно на половину размера, а остальная часть игрового объекта обновляется реже. Другое дело, что документ будет обновляться только во всей футбольной игре и никогда больше, поэтому я начал с одного документа. – marto

+0

Нет недостатка в наличии многих документов, поэтому я не вижу смысла иметь все вместе в игровом документе. Зная, что ваш игровой документ будет 1 МБ, что в значительной степени - я бы определенно рекомендовал иметь отдельные документы для событий, чтобы избежать загрузки и обновления всего игрового документа. –

Смежные вопросы