views:

46

answers:

1

I'm really new to database object design so please forgive any weirdness in my question. Basically, I am use Google AppEngine (Python) and contructing an object to track user info. One of these pieces of data is 40 Achievement scores. Do I make a list of ints in the User object for this? Or do I make a separate entity with my user id, the achievement index (0-39) and the score and then do a query to grab these 40 items every time I want to get the user data in total?

The latter approach seems more object oriented to me, and certainly better if I extend it to have more than just scores for these 40 achievements. However, considering that I might not extend it, should I even consider just doing a simple list of 40 ints in my user data? I would then forgo doing a query, getting the sorted list of achievements, reading the score from each one just to process a response etc.

Is doing this latter approach just such a common practice and hand-waved as not even worth batting an eyelash at in terms of thinking it might be more costly or complex processing wise?

+2  A: 

I like the simple idea of keeping the list of 40 ints, but you can't force feed it into App Engine's existing User class, whose layout is determined by the GAE API (and doesn't include those 40 ints). So that list will inevitably need to live in a separate entity (i.e., each instance of a separate model).

Alex Martelli
I didn't realize there's a User class. What I meant is I have my own MyUser entity where I can declare a list of 40 ints. What I was looking for was whether it was generally an extremely inconsequential optimization to use 40 ints rather than create a separate entity type to contain that data, then have to query those every time I wanted to get info on a particular user, etc.Thanks for your response. I'd follow up to that response with wondering at what point it's better to break out into a separate entity or keep with multiple 'list of 40 things' in my MyUser class to avoid querying.
Joey
@Joey, the cost of a query is a constant plus a term proportional to the entity's size; storing (and inevitably fetching every time) data you don't always need thus has performance costs (larger entities) wrt splitting it off, as well as pluses (fewer queries), so "at what point" one or the other design is better depends on the probability that such extra data will or won't be needed on each fetch of the main entity.
Alex Martelli