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
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
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
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
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
