By denormalize, I mean storing the CD titles in the Ownership entities as well. Yep, there'll be duplication to avoid the join, but you'll be able to get the CD titles from the fetched Ownership entities in one query.
I'm still trying to figure out best practices myself with the datastore. When joins are expensive or impossible, you can turn to denormalization but just how you do it depends on the queries you expect to run (and optimize for). Here's an interesting article that has some relevant links: http://www.codinghorror.com/blog/archives/001152.html You can see your initial User entity with all the counters was an intuitive use of denormalization. The only problem is the added constraint of indexed properties caps. On Jan 18, 12:07 pm, Chen Harel <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
