Andreas, I have a very similar application. It tracks a league's season, team, player, and game scores / statistics. I needed to have isolation between leagues and within leagues between seasons, teams, players. Basically the approach I settled on was adding a "league" and "season" property to most of the models.
When a user logs in they must select a league they have permissions to access or manage, I store the league key in a datastore-backed session. Any time they access something I verify that the league key matches, and, of course, any queries I run filter out content from different leagues. I continue this approach down to the lower level items (players and games for example). I do use entity groups, but at a much finer level, and they may not really be needed at all. For storing statistics I have models like PlayerSeason, PlayerWeek. I put Player, PlayerSeason, and PlayerWeek into the same entity group. Likewise for the teams and their stats. I did this so that if a part of my db.put() that stores all games and related statistics models fails I do not have players or teams getting mismatched within themselves -- not really sure it helps much though. Robert On Thu, Dec 3, 2009 at 9:07 AM, andreas_b <[email protected]> wrote: > I chose the wrong wording in my original post. I didn't mean actual > full databases, but something like a schema yes. > Have a lot to learn when it comes to efficient database usage in any > case :-). > > Actually I'm not using the LLAPI for portability reasons. I don't want > to build too many dependencies on a particular web service, so > I chose JDO instead, although LLAPI seems a bit more powerful. I might > actually look into it to gain more flexibility. > > Thanks for the tip! > > BR, Andreas > > On Dec 3, 2:19 pm, Roy <[email protected]> wrote: > > In an RDBMS world you would actually create a schema for each team, > > not a full database (unless you have a morbid need to drive your > > sysadmin to an early grave). I did make a feature request for this, > > but you know how it is with GAE feature requests. > > > > If you're using LLAPI, there is actually a very simple trick that will > > work, Append the team name to the kind. > > So instead of a kind called "player", you have kinds called "player- > > spurs", "player-w19an", etc. > > > > You can have a very simple customer data access layer which does this > > automatically based on a session variable. > > > > I use this trick for testing. Whenever I login using a designated test > > username, I append "-test" to my kind names so that I'm not missing > > live and test data in a single dataset. > > > > On Dec 3, 7:53 am, andreas_b <[email protected]> wrote: > > > > > Thanks both of you! > > > > > Very helpful answers. > > > > > Best Regards, Andreas > > > > > On Dec 2, 8:24 pm, "Ikai L (Google)" <[email protected]> wrote: > > > > > > Creating a database per team is a very heavyweight way to address the > > > > problem of data segregation. This is unnecessary and in general, not > a > > > > recommended best practice, as you would provide data isolation at the > > > > application layer. The intuitive solution here is to create an entity > group > > > > for a league or team (depending on your transactional needs) and > place child > > > > entities in that group. > > > > > > On Tue, Dec 1, 2009 at 10:40 AM, andreas_b < > [email protected]>wrote: > > > > > > > Hi all. > > > > > > > I'm working on a GWT/GAE project where the idea is to create a > portal > > > > > for sport teams. Each sport team can sign up to get an account > where > > > > > they can register players, keep track of leagues, matches, > statistics > > > > > and so on. Each team should also be able to use their own domain, > > > > > which automatically should load the site with their configuration > when > > > > > entered (basically just load the gwt-app with some url-parameter > that > > > > > is forwarded to server-side). > > > > > > > So, coming from a normal SQL-environment, it seems to me that each > > > > > team that signs up should get their own private database for all > their > > > > > data. As I understand it, this is not possible with GAE datastore? > > > > > There is a one-to-one mapping between an application and a > datastore? > > > > > > > If this is the case, then what is the best way forward? I guess > each > > > > > entity could have a team ID, but it really doesn't seem like a good > > > > > idea. There should be some kind of isolation between the different > > > > > teams' data. > > > > > > > Registering a new GAE app for each team is not an option either > since > > > > > we expect at least hundreds of teams. > > > > > > > So, is there some way to isolate entities from each other within a > GAE > > > > > datastore? > > > > > Also, would it be feasible from a performance point of view to do > > > > > this? > > > > > > > Or is simply GAE not the right way to go for this kind of web > > > > > offering? > > > > > > > Thanks in advance. > > > > > > > BR, Andreas > > > > > > > -- > > > > > > > You received this message because you are subscribed to the Google > Groups > > > > > "Google App Engine" group. > > > > > To post to this group, send email to > [email protected]. > > > > > To unsubscribe from this group, send email to > > > > > [email protected]<google-appengine%[email protected]><google-appengine%2Bunsubscrib > [email protected]> > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/google-appengine?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" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-appengine%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" 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?hl=en.
