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 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
> google-appengine-j...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com
> .
> 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 google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
