On May 4, 3:28 am, "Ikai L (Google)" <[email protected]> wrote: > Query performance is generally a function of how many objects have to be > returned in the simple case, which seems to be what you are doing here. How > many PlayerGameStates exist per User?
No more than 10 so far. Like I said, it was only 5 in this case. > Are PlayerGameStates child entities of a User? No. They contain a userKey, which is the field on which I'm querying them. > The reason I mentioned "denormalizing" is because the concept of > normalization doesn't make as much sense with App Engine's datastore. We > don't provide referential integrity, for instance, and transactions exist > around entity groups, not globally. You don't pay a penalty for storing data > that is sparse - some User entities can be huge, some can be tiny. You > should optimize for reads. Doing multiple writes and the risk of data > getting out of sync can suck, but as long as it is recoverable you should be > okay. Contrast the performance of the query above with storing > PlayerGameStates inside User. You'd do this: But then I'd have to run a separate query to fetch the game. Unless I duplicate the game state and move all those fields into PlayerGameState, which perhaps is what you're suggesting. But then I'd have to fetch both users every time, right (to update the duplicate game state), which means every player needs to contain the userKey of everyone they're playing. Most of my reads are by gameKey. There's only one case where I'm fetching all the games for a user. I don't really need this case to be optimized: 2-3 seconds would be acceptable. 80-90% of the time it's ~1 second. But these occasional 10-20 second fetches are crazy. -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
