I have the same question but this is leading to much bigger relationship model.
As students, they may not have many exams, but I am working on an app for financial institute so a banking client has more than 100,000,000 transactions for different account. Therefore, should I group all transactions into the same entity group of one account or should I still leave it separate and let an account object contain 100,000,000 keys? Thanks in advance WillSpecht wrote: > http://www.google.com/events/io/2009/sessions/BuildingScalableComplexApps.html > > this is a pretty good discussion on building apps that have lots of > child objects. I also think you are prematurely optimizing. How many > exams is a user going to have? 100, 200? This is still a tiny number > and if you went with RB's method or the one in the link I posted, you > have to run a separate query each time, which has its own costs. I > think either way is fine until you start having users that have > thousands of exams. > > On Dec 21, 3:05 am, Richard Berger <[email protected]> wrote: > > Har_Shan: > > > > I have been thinking about this topic also (but sadly, am not much of > > an expert). I am using Objectify as a layer on top of the Datastore. > > Their website has a lot of good information on structuring data in the > > Datastore - > > seehttp://code.google.com/p/objectify-appengine/wiki/Concepts?tm=6 > > ). > > > > There is also a good post on the various ways of handling 1 to many > > relationships using Objectify. What appeared to be something that > > would work in your situation (which is like my situation) is what I > > think of as the "database approach". What I mean by that is, if you > > had a 1 to many relationship, how would you model that in a database? > > Specifically if 1 User can have Many Exams, you would have... > > > > User table > > * userId > > * Other user fields > > > > Exam table > > * examId > > * userId > > * Other exam fields > > > > So, turning this into GWT/Objectify, it would be.... > > > > public class User { > > @Id private Long id; > > // Other user fields > > > > } > > > > public class Exam{ > > @Id private Long id; > > private Key<User> userKey; > > // Other exam fields > > > > } > > > > The way to find all the exams for a particular user (represented by > > "this") is: > > Objectify ofy = ObjectifyService.begin(); > > Key<User> userKey = new Key<User>(User.class, this.id); > > List<Exam> result = ofy.query(Exam.class).filter("userKey", > > userKey).list(); > > > > This is explained (much better than I could do) > > at:http://code.google.com/p/objectify-appengine/wiki/IntroductionToObjec... > > > > This may not solve all (or any) of your use cases, but it has worked > > for me in my admittedly very limited usage. > > Also check > > out:http://groups.google.com/group/objectify-appengine/browse_frm/thread/... > > > > Enjoy, > > RB > > > > On Dec 19, 12:17 am, Matej <[email protected]> wrote: > > > > > I am not expert in dataStore this is just what I would do: > > > Add new entity with fields: > > > ID OrderID UserID ExamID PageID QuestionID AnswerID > > > > > Yes it is a lot of redundant data, but simple. > > > When user starts new Exam, all data are created with AnswerID set to > > > general answer unAnswer. After that you just update AnswerID. > > > > > What are obstacle in design like this? > > > > > Best, M -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" 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-java?hl=en.
