In regards to fewer, fatter, denormalized objects, this isn't unique to appengine, it's a NoSQL standard best practice. Doing single fetches by key aren't all that more expensive than looking something up in memcache (in terms of time taken).
On Feb 22, 12:58 pm, adamd <adambo...@gmail.com> wrote: > Thanks for you're replies, really helpful. > > Marcelo - just to be clear, are you talking about Memcache? I haven't > played with it much yet, but I was under the impression there wasn't > enough space there for everything, in order for there to be "no > further access to the datastore" as you say. > > Adam > > On Feb 22, 5:28 pm, Marcelo Nunes <marcelopereiranu...@gmail.com> > wrote: > > > > > > > > > I think you are missing the point. The goal of this App Engine way is to > > *force* you to use cache, You only have to query once when the data is > > modified, then you store the results on a server cache and you can serve as > > many page views you want with no further access to the datasore, Super fast > > and with no extra charge. > > > But doesn't it mean I'll have lots of data in cache? > > > Yes, but that is the point: no matter how fast HRD can be, a replicated > > database will never be as fast as a standalone RDBMS for most trivial > > queries. So, it is not because Google wants profit more on your queries, > > but the fact is that you can never have an efficient webapp or webpage > > based on a cloud-based service if you don't do a lot of caching. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
