James, The way I would probably do this would be to create an enum in the scope of the Membership class representing a region and store it as an indexed property. The App Engine data store will take care of distributing the CRUD operations of related data for you. You probably won't get much bang for your buck by creating different entities. By maintaining a single Membership entity, you'll be able to more easily reuse related class. At its most low level, the App Engine datastore is simply a distributed, type agnostic key-value store. App Engine recognizes entities by creating an index for all of your application's Entities, and indexes are created for each property by default. I would recommend creating a Data Access layer and doing the segmentation there.
On Tue, Nov 10, 2009 at 1:48 PM, James H <james.hollier...@gmail.com> wrote: > > Is there a best practice entity design for storing Membership data > that targets a global market? Ideally, the Membership data is > partitioned geographically since a Membership in the U.S. is > independent of one in the U.K. and elsewhere, for example. The motive > is that operations (searches, inserts, updates, deletes) on U.S. data > need NOT involve data from the U.K. and elsewhere. Can GAE > transparently provide this based on the design of a single Membership > Entity or do you have to create separate Entities for each region in > your design such as MembershipUS, MembershipUK, etc? > > > -- 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-java@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 -~----------~----~----~----~------~----~------~--~---
