@Eli, Actually, I have done this on production server with other web applications. Databases that are 'well indexed' summary data (count by group) are actually FAST. The system should be able to count index items, not node leafs and as such usually perform ~better~ than full scans.
*w/ Sybase 11.5 and higher* It would surely be more efficient than what I would write to load all the objects, figure out if I have a new one and add it to a collection, increment a counter then destroy all the objects. (by logic, not practical observation of object graph navigation) It still seems like a very limiting weakness. Judging from the number of times it comes up that is something people seem to want / need. ** Speaking of, It is also my understanding we 'can't connect to remote data sources' directly (JDBC) but could make RESTful webservice requests ** (Again, bloated XML by logic this also seem to be a heavy solution.) Does the Datastore run on the same physical server as the appsever. I would think NOT for scalability. Thanks for bearing with me. > > Topic: Summary data ( I read the FAQ). > > Eli Jones <[email protected]> Feb 22 05:34PM -0500 ^ > > This is a fundamental limitation of the datastore.. and is what allows it to > scale out. > > Imagine if facebook tried to do a Sum() for a column over a table made out > of 100 shards that existed on 50 different federated database machines... > they can.. but not with some fancy built in db function. They give up that > ability so they can scale out.. > > So.. if you want to process your data like you would on your own personal > database.. then you need to do a dump of your datastore data.. and process > it offline in your own personal database. > -- 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.
