Hi, I'm not sure I've followed you with whole Ownership model.. Isn't that a RDBMS approach to the data and not BigTable's?
Regarding the genres, they are fixed (53 to be exact) and he can't select new genres that aren't in the predefined list. Regarding the counter entity, this is basically what I have today, Simply that instead of using a ListReference I will save the string 'trance' to a ListStringProperty... So I can get for a cd the tuple: "name:world music 2008 genres:[indy, house, foreign]" On Jan 16, 11:54 am, Bill <billk...@gmail.com> wrote: > You could do an entity that has 50 genre counters. > > Some thoughts: > > 1) It seems like you can make genre part of a list property in a CD > since each CD will only be a small number of genres. > > 2) I wouldn't use a Reference List for a User entity, because a User > might have thousands of CDs. See Rafe Kaplan's article on modeling > entity relationships (http://code.google.com/appengine/articles/ > modeling.html). I'd model the User <-> CD relationship with a > separate Ownership entity that has key references to a CD and User > entity. You could add additional info into this relationship model, > like whether the Owned CD has been lent to another User. > > 3) Are genres fixed or user-configurable (like a "tag" instead of a > universal genre)? If they are like tags and user-configurable, you > could but the genre list in each Ownership entity. Then if User X > wants to know how many "1980s Top Hits" he owns, you could query the > Ownership entities. You could then memcache the (User, Genre, #CDs > for genre) tuple instead of keeping 50 counters in User and just query > again if needed. > > -Bill > > On Jan 15, 2:23 am, Chen Harel <chook.ha...@gmail.com> wrote: > > > Hi, In case I want to represent a music album datastore, > > I wish the user can add a cd that he likes (no need for information > > other than cd name and genres) > > Now, at first I looked at it as a RDBMS even in BigTable, meaning I > > had > > User entity > > CD entity > > Genre entity > > With list of refrences keys... > > Now after playing with it, I realized (at least I think so) that I am > > killing my application, > > Since I need to be able to supply the aggregations on "how many R&B > > cd's user XXX has" > > this query can't be optimized (at least with my current knowledge) on > > BigTable, > > So I need to start putting up counters... but I am questioning you > > about the number of properties allowed (or make sense) > > If I support 50 genres, can I simply do an entity that has: > > User: > > id > > name > > cds (list of refrences) > > total_cd_counter > > trance_cd_counter > > house_cd_counter > > rnb_cd_counter > > .. (47 more counters) > > > And when I add / remove a cd for a user, I shall update the > > appropriate counter ... > > This will make query for the favorite genre (which is the main goal :) > > - Sorry I got to it only here) of the application... > > > Please tell me if this will work, and will have sufficient > > performance / scaling capabilities... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
