Depending on your entity group/transaction strategy here you might want to consider Referencing Users to a Dislike/Like Kind:
http://code.google.com/appengine/docs/python/datastore/datamodeling.html#References What happens is (and premature i can say so) your like, dislikes properties are going to generate a lot of zig-zagging (due to merge join) when you query for this information (also depending on your index strategy) class User(db.Model): ..... class Like(db.Model): topic = db.StringProperty() #enumeration user = db.ReferenceProperty(User) class Dislike(db.Model): topic = db.StringProperty() #enumeration user = db.ReferenceProperty(User) Your key strategy can be (serial of topic + user.key().name()) And then you can use a pipeline to go thru your Like, Dislike structures and build a de-normalized Kind you can query safely on. - i think - On 9 June 2011 14:49, King <sirhc...@gmail.com> wrote: > Hi all :) > > Let's say I have a app called "Opposites Attract". And in it I have a * > User* model, and each user has a list of *Likes* and a list of *Dislikes*. > > Each USER can have a maximum of: > - 200 Likes. > - 200 Dislikes. > > I want to query this information to find out for a given *Like*, what > other users *Dislike* it or vice versa. I don't need to return EVERY > person that likes or dislikes a particular thing. If I just returned the > first 100 people found to like/dislike a particular thing, that would be > acceptable. *How would it be best to model this?* > > Here (http://code.google.com/appengine/articles/modeling.html) it speaks > of a potentially similar example under the *Many to Many* example, and if > I were to implement it in this way, I would have a class like so: > > class User(db.Model): > likes = db.ListProperty(db.Key) > dislikes = db.ListProperty(db.Key) > > where the keys in both lists would refer to items from a *Thing* model. > > What I'm wondering is in the App Engine Documentation's example they > mention: > "In the example above, the Contact side was chosen because a single person > is not likely to belong to too many groups, whereas in a large contacts > database, a group might contain hundreds of members." > * > With that quote in mind, does this method suit my example?* I want to > design this app so that hundreds of thousands of people can like or dislike > a thing. So I would feel better if the above quote read "whereas in a large > contacts database, a group might contain hundreds (OF THOUSANDS) of > members." > > Also though I expect this doesn't change how I model this particular > relationship I feel I should mention this in case it does: > While my concern at the moment is searching ALL users that like or dislike > a particular thing, my next step would be to search by *Gender* and * > Location* > For example: > "all GIRLS who likes Dogs" > "everyone in Los Angeles who dislikes Cats" > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-appengine/-/m3lX4RQ3FXoJ. > 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. > -- http://about.me/david.mora -- 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.
