Ok, If I go with number 1, I'm not sure how can I denormalize it to print the CD titles... If I can't "join" on the CD titles them selves... How can I fetch the names of the CDs if the select is SELECT * FROM Ownership WHERE user_id = <user_id> ?
Bill, 10x a lot for your help... On Jan 17, 10:13 am, Bill <[email protected]> wrote: > 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. > Seehttp://groups.google.com/group/google-appengine/browse_thread/thread/... > > 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 <[email protected]> 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 <[email protected]> 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 [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?hl=en -~----------~----~----~----~------~----~------~--~---
