Я пытаюсь обернуть голову вокруг групп объектов и иерархических ключей в ndb
, но я мог бы застрять в «нормализованном мышлении». Я хочу вычислить и сохранить рейтинг разных игроков в зависимости от того, как они делали в разных матчах друг против друга с течением времени. Но все, что я могу придумать, чтобы сохранить «внешние ключи» в виде строки, как это:Как моделировать Player, Match и EloRank как объекты NDB
class Player(ndb.Model):
name = ndb.StringProperty()
class Match(ndb.Model):
player1_key = ndb.KeyProperty(kind=Player) # pointing to Player entity
player2_key = ndb.KeyProperty(kind=Player) # pointing to Player entity
player1_score = ndb.IntegerProperty()
player2_score = ndb.IntegerProperty()
time = ndb.DatetimeProperty(auto_now_add=True)
class EloRank(ndb.Model):
player_key = ndb.KeyProperty(kind=Player) # pointing to Player entity
match_key = ndb.KeyProperty(kind=Match) # pointing to Match entity
rank = ndb.IntegerProperty()
time = ndb.DatetimeProperty(auto_now_add=True)
Конечно, это было бы легко «денормализовать» данные по скопировать его (т.е. Match есть два ключа к югу, один для игрока 1 и один для игрока 2), но как я могу, например, изменить имя игрока, не прибегая к выполнению обновлений в каждом объекте Match? StructuredProperty
также не является ответом, так как они принадлежат к определяющему объекту.
Как бы вы переписали эту модель, чтобы поместить объекты в одну группу?
Update Используйте KeyProperty
вместо StringProperty
как предложено M12.
Спасибо. Да, 'KeyProperty' кажется хорошей идеей, но это просто даст мне проверку типа, так что я могу назначить ключи соответствия свойствам совпадений и т. Д. Мне было интересно, как« сформулировать »эту модель как группу сущностей , – Kalle
Вы не согласитесь, что матч не принадлежит одному игроку. Каждый матч будет его собственной группой. Было бы разумно, чтобы игрок был потомком EloRank - он принадлежит группе лиц Игроков, тогда KeyProperty для Player является избыточным. –