Is there a reason you want to avoid hard coding roles? I can certainly understand from an OO purists perspective why that can leave a nasty aftertaste, but if you have a finite set of roles, it isn't the worst thing in the world. In fact, it may simplify your overall design. To me, join classes when there are only a very small set of possible roles feel unnecessary.
>From a datastore perspective, you aren't creating columns. You are creating a typeless entity that is stored in key-value storage, with only attributes containing values being indexed. That is: if a Partner has a Teacher and Student but no Employee, only those Teacher and Student values are indexed. As far as denormalization is concerned, App Engine heavily favors small requests over larger requests that require more calculations at request time. What this means is that you are encouraged to calculate denormalized value at write time such that reads can happen very quickly. It seems like denormalization can work very well in your situation, but this is a decision you'll have to make based on the needs of your application. On Sun, Dec 20, 2009 at 2:39 AM, mirko <[email protected]> wrote: > I am new to the persistence model of the Google app engine and have a > question on how to best model/architect the following scenario. I > would really appreciate your feedback! > > The Partner class can 0-n roles "implemented" (Teacher, Student, > Employee, ...). > > Partner > - Key > - Name > - RoleList > > Role abstract > - Key > - RoleType > - RoleDescription > - Partner > > Employee extends Role > - Salary > > Teacher extends Role > - Classes > > Student extends Role > - Grades > > I would like to avoid "hard coded" relationships in the partner class > (meaning having properties pointing to every available role). In > addition I need to be able to query the different roles, but also need > to be able to show all "implemented" roles of a particular partner. > > What would be the best model to architect the mentioned scenario? > Is there an option in extending Role and having a list of > "implemented" roles in the Partner object? > Does this all make sense or would you re-architect this whole problem > differently? > Would you denormalize and embed the Partner class in each of the role > classes? > > Thanks, Mirko > > > > > > There are different options I see so far on how to and I would like to > store the different facets > > -- > > 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]<google-appengine-java%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > > > -- Ikai Lan Developer Programs Engineer, Google App Engine -- 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.
