Thanks both of you!
Very helpful answers.
Best Regards, Andreas
On Dec 2, 8:24 pm, "Ikai L (Google)" 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
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
So I've spent some time now reading more about the datastore and I
find it hard to get a complete picture about how it works from the gae
docs and articles.
In my case, I must make sure there is some implicit isolation of the
different team's data. So after reading more about entity groups, it
seem
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
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
Andreas,
The datastore provides virtually no security mechanisms for data
partitioning within the same application. The responsibility for access
control belongs in your application layer.
On Thu, Dec 3, 2009 at 8:28 AM, Robert Kluin wrote:
> Andreas,
> I have a very similar application. It
