Question

问题看起来像一个开放式问题。为了使其更具体，让我用一个示例场景来解释。

假设玩家P1，P2，...，Pn为T1，T2，......，Tm队效力。每年球队都会竞选球员，因此球员会继续改变球队。

在关系数据库中，玩家和团队模式之间存在N对N关系。我们可以轻松地从关系数据库中获取以下信息： -

球员P1在整个职业生涯中的进球数是多少？
球员P1在整个职业生涯中为T1队打进多少球？

在关系数据库中，目标可能是N-N关系PlayerTeam的属性。回答（1）只是一个聚合SUM查询，（2）是一个简单的选择查询。

我们如何在Google App Engine数据存储区中组织团队和玩家？以及如何在数据存储中运行上面的查询（1）和（2）？

Answer 1

这是一种简单但可行的方法：

import ndb

class Player(ndb.model):
    name = ndb.StringProperty(required=True)
    # rest of Player model snipped

class Team(ndb.model):
    name = ndb.StringProperty(required=True)
    # rest of Player model snipped

class Goal(ndb.model):
    player = ndb.KeyProperty(Player, required=True)
    team = ndb.KeyProperty(Team, required=True)

def playerNumGoals(player):
    qry = Goal.query().filter(Goal.player == player.key())
    return qry.count()

def playerTeamNumGoals(player, team):
    qry = Goal.query().filter(Goal.player == player.key(),
                              Goal.team == team.key())
    return qry.count()

因此，除了您使用显式查询而不是连接之外，在这种情况下与关系方法没有太大区别。有了适当的指数，它就差不多了。

其他用例更加困难，并且可能需要更深层次的重组（并且通常需要一定程度的去规范化）来解决缺少连接问题 - 在ndb中，就像在任何其他NoSQL数据库方法中一样。 ndb有自己的额外怪癖（例如，某些属性不能选择不同于23但是由不同的属性排序）如果你处理的是大量的数据，有时需要大量的聪明才智... < / p>

如何从关系数据库思维模式转变为应用程序引擎数据存储区？

1 个答案: