On Mon, Apr 6, 2009 at 8:53 PM, Marcel Overdijk wrote:
> (1) Now what I want to collect is the average value per month.
> E.g
> - User1, 1 jan 2009, 1000
> - User1, 1 feb 2009, 1100
> - User1, 1 mar 2009, 1200
> The avarage will be 100
>
> But maybe the user misses registering the meter reading on
On Apr 7, 6:53 am, Marcel Overdijk 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
The average is maybe not the correct description, better is to call it
usage.
On 6 apr, 22:46, Alkis Evlogimenos ('Αλκης Ευλογημένος)
wrote:
> On Mon, Apr 6, 2009 at 8:53 PM, Marcel Overdijk
> wrote:
>
> > (1) Now what I want to collect is the average value per month.
> > E.g
> > - User1, 1 jan
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
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 BigTab
