Hi Marcel, the SQL join world saves you the hassle of thinking about all of this stuff at write-time, but would not scale beyond a few thousand users. if you implement everything in SQL and then end up with a very busy site, you end up re-implementing all of your data access to work in the BigTable way.
one nice thing about BigTable is that when you do a db.put(entities) where entities is an array/list, it sends them away to write in multiple threads. so the access time is not linear with len (entities). sharded counter = awesome Ben On Apr 7, 2:48 am, Marcel Overdijk <marceloverd...@gmail.com> wrote: > This would mean really a lot of updates. > > E.g. > - User1, 1 jan 2009, 1000 > - User1, 1 feb 2009, 1100 > > This would mean craeting an avarage usage of 100 for jan 2009. > > Now next time the user enters a meter reading is e.g. 1 jan 2010 with > value 2300. > This would mean in this case createing avaerage use valuues for feb, > mar, apr, may, jun, jul, aug, sep, okt, nov and dec 2009. > > And als updating average usage of all users. > In a SQL join this would be less dificult and error prone to > implement. > > I'm wondering if my use case fits the BigTable principles and thus > GAE, or that I would be better of with a realtional database. > But this would mean I can't use GAE and have to go for another cloud > solution like mor.ph > > On 7 apr, 06:36, GregF <g.fawc...@gmail.com> wrote: > > > > > On Apr 7, 6:53 am, Marcel Overdijk <marceloverd...@gmail.com> wrote: > > > > - User1, 1 jan 2009, 1000 > > > - User1, 1 feb 2009, 1100 > > > - User1, 1 mar 2009, 1200 > > > The avarage will be 1100 *** > > > > But maybe the user misses registering the meter reading on 1 feb: > > > - User1, 1 jan 2009, 1000 > > > - User1, 1 mar 2009, 1200 > > > The average will still be 1100 *** > > > I guess the answer will be to store average values when creating (and > > > updaing existing) meter reading records. > > > But how should this be implemented? > > > *** Corrected. > > > Yes, calculate averages when you update the table. If you don't need > > to search for particular readings, you might want to store the meter > > readings in a db.ListProperty(int), with an associated db.ListProperty > > (int) of timestamps. > > > I need to count various things in my app, so I define a model and > > helper functions like this: > > > class Counter(db.Model): > > count=db.IntegerProperty(required=True,default=0) > > > # Increment a counter > > # NB: These are functions, not class members > > def _incrementCounter(counterId,amount): > > counter=Counter.get_by_id(counterId) > > counter.count+=amount > > counter.put() > > def incrementCounter(counterId,amount=1): > > db.run_in_transaction(_incrementCounter,counterId,amount) > > > I'm sure you can do something similar for your averages. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
