Реплицированные данные в сравнении с несколькими поисками в Google App Engine - дизайнерское решение - PullRequest
Новая
       2

Реплицированные данные в сравнении с несколькими поисками в Google App Engine - дизайнерское решение

0 голосов
/ 15 июля 2011

Я всегда ловлю себя на этой проблеме с Google App Engine: повторять ли данные, хранящиеся в других объектах, или связывать?Что я должен проанализировать, чтобы принять это решение?

Я не буду использовать эту информацию при поиске, так что это не «проблема объединения GAE», это вопрос стоимости.

Правильнотеперь у меня есть что-то вроде этого грубого примера: 

public class GameResult
{
    private int points;
    private int duration;
    ...
}

public class Player
{
    private string name;
    private GameResult lastGameResult;

    List<int> lastGamesPoints;
}

Каким-то образом мне нужно знать пунктуацию последних 5 игр, и это единственная информация, которая мне нужна, то есть мне не нужно знать другиематериал о GameResult из прошлых игр.У меня может быть этот Список целых, или у меня может быть ассоциация OneToMany с GameResults.

1 Ответ

0 голосов
/ 19 июля 2011

Это действительно зависит от вашего реального использования и узкого места.Если вам не нужно изменять эти данные, будет хорошей идеей дублировать их на разные объекты.Особенно, когда вам нужно получить эти «последние пять результатов» (запрос с помощью order_by).Если вы используете модель отношений «один ко многим», это означает, что вам нужно потратить несколько часов ЦП, чтобы сначала их проиндексировать.Затем вам нужно потратить дополнительный процессорный час на запрос этих результатов.Я не думаю, что это хорошая идея.Другим способом сделать это будет использование ListProperty для хранения последних пяти сущностей GameResult.Это означает, что вы можете извлекать эти сущности с помощью их ключей, которые будут выполняться быстрее, чем запрос.

Для получения дополнительной информации, есть несколько отличных постов для чтения! Реляционное и нереляционное моделирование данных - в чем разница & Как думать в хранилищах данных вместо баз данных?

...