[google-appengine] Re: Best way to model relations

2010-01-06 Thread Satoshi
First of all, please remember that GAE/database is an Object-database, not a Relational-database. You can design your database with relations, but you will likely hit a roadblock later if you heavily rely on relations (because of the lack of JOIN and the performance problem of nested queries). If

[google-appengine] Re: Best way to model relations

2010-01-07 Thread Satoshi
I'd add "reference_count" property (IntegerProperty(default=0)) to Photo entity, and increment it each time a reference happens. Then, call Photo.all().order("-reference_count").fetch(100) to get the top 100 most referenced photos. A few additional notes: 1. If you need an accurate reference count

Re: [google-appengine] Re: Best way to model relations

2010-01-06 Thread Robert Kluin
Satoshi made very good suggestions. Also, remember that because there are no JOINs or efficient sub-queries, you need to denormalize your data a lot too. So if you want something like a list of photographs with artist name you may want to store the artist's name on the Photo entity too (along wit

Re: [google-appengine] Re: Best way to model relations

2010-01-06 Thread Daniel Aguilar
Hi Satoshi, thanks for your reply, it really helped. In fact I just read this artile: http://code.google.com/appengine/articles/modeling.html and have started implementing based on it. Still wondering a couple of things, though... for instance, in my app I have another class called Collage. A coll

Re: [google-appengine] Re: Best way to model relations

2010-01-06 Thread Robert Kluin
The datastore has no aggregation functions. To get that type of summary data you will want to precompute it. Robert On Wed, Jan 6, 2010 at 7:15 PM, Daniel Aguilar wrote: > Hi Satoshi, > > thanks for your reply, it really helped. > In fact I just read this artile: > http://code.google.com

Re: [google-appengine] Re: Best way to model relations

2010-01-11 Thread Daniel Aguilar
Hi again, thanks a lot for your answers. So it looks like developing for GAE is quite a different paradigm... >From your answers i understand that: 1. I should precompute and store all aggregated data I might need 2. Changes to my database are NOT immediate (hence I can't expect accuracy) I will