Chen, Some differences between using an Ownership model and using a list of references to CDs in a User entity:
1) You can store info associated with Ownership as mentioned in my previous message. So if you want to print all the CD titles owned by a user, you could denormalize CD titles and duplicate that information in Ownership entities. Then, you do a query on Ownership entities filtering for a specific User and the titles would be fetched. In the list of references, you'd have to actually retrieve each CD title or store titles in the single User entity, which leads us to #2... 2) There's a cap on number of indexed properties. See http://groups.google.com/group/google-appengine/browse_thread/thread/d5f4dcb7d00ed4c6 I haven't tested this yet, but the cap on indexed properties will really hamper your ability to have huge reference lists within a User entity. However, you could pickle/serialize your CD data into a blob or text property which aren't indexed. If you start storing the CD lists as blobs, though, you lose the ability to do queries like "Show me all users that own CD X" On Jan 16, 11:05 pm, Chen Harel <chook.ha...@gmail.com> wrote: > Bill if I use an ownership model, > How do you fetch all the cds of a user? > you select on Ownership, then get the tuples with user id / cd id > Now you need to fetch many cd id from the CD entity.. > So what's the difference? > If you store them as a list of IDs in the User, you still have to go > over the CD and fetch for every ID, > This still doesn't allow you to properly index your data, does it? > > On Jan 16, 8:14 pm, Bill <billk...@gmail.com> wrote: > > > > 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? > > > The two approaches aren't mutually exclusive. In the case of User <-> > > CD, a User can have thousands or more CDs and a CD could be purchased > > by millions. Under those circumstances, storing the ownership > > relationship in a list of references under either User or CD entities > > will really impact performance. > > > In Rafe Kaplan's article he says: > > "Another more important one is that you want to avoid storing overly > > large lists of keys in a ListProperty." > > > The straightforward alternative is a separate Ownership model and now > > there's a separate issue of constructing a transaction that handles > > updating your genre counter upon a successful Ownership change. > > > It'll be interesting if someone comes up with another approach, maybe > > using multiple User entities (under one entity group) that all map to > > a single user, with each User entity holding a subset of all the CDs > > and genre counters. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
