CODEWITHSUNDEEP
google-app-enginegoogle-cloud-datastoredata-modeling
Pankaj Jangid
Pankaj Jangid

Reputation: 612

How to move from a relational database mindset to app-engine datastore?

The question looks like an open ended one. To make it more specific let me explain with an example scenario.

Suppose players P1, P2, ..., Pn play for teams T1, T2, ..., Tm. Every year the teams bid for players and hence players keep on changing teams.

In a relational database, there is a N-to-N relationship between Players and Teams schemas. We can easily fetch the following information from a relational database:-

  1. How many goals the player P1 has scored in his whole career?
  2. How many goals the player P1 has scored for team T1 in his whole career?

In a relational database, goals may be an attribute of N-N relation PlayerTeam. And answering (1) is just an aggregate SUM query and (2) is a simple select query.

How do we organise teams and players in Google App Engine Datastore? And how to run queries (1) and (2) above, in Datastore?

Upvotes: 0

Views: 62

Answers (1)

Alex Martelli
Alex Martelli

Reputation: 881497

Here's a simplistic but workable approach:

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()

So, not very different in this case from a relational approach, except that you use explicit queries rather than joins. With appropriate indices, it's just about equivalent.

Other use cases are much harder and may require a deeper restructuring (and often some level of de-normalization) to work around the lack of joins -- in ndb just like in any other NoSQL database approach. ndb has its own extra quirks (e.g can't select by some property being different than 23 but order by a different property) which can sometimes require substantial ingenuity if you're dealing with impressive masses of data...

Upvotes: 1

Related Questions