PFZ.nl - PHP Community: Verbruik per maand --> verschil tussen waarden uit 2 rijen berekenen - Databases - Forum - PFZ.nl - PHP Community

Goedemiddag,

Ik wil het gasverbruik per maand gaan berekenen. Ik ga er (voorlopig) vanuit dat er slechts 1x per maand een stand wordt ingevoerd, maar dat kan later altijd nog ooit veranderen. Dus bv. op 1 maart wordt de beginstand van maart ingevoerd (= eindstand februari), op 1 april wordt de beginstand van april ingevoerd (= eindstand maart) etc. etc. Dit zou de volgende tabel kunnen opleveren:

1 2 3 4 5 6 7

+----+------------+-------+ | ID | Datum | Stand | +----+------------+-------+ | 1 | 2011-03-01 | 23175 | | 2 | 2011-04-01 | 23312 | | 3 | 2011-05-01 | 23389 | +----+------------+-------+

Nu wil ik het verbruik per maand gaan bepalen. Dat lukt me (uiteraard) wel met PHP, maar kan ik dat ook met SQL doen? Mijn gevoel zegt dat dat namelijk sneller zou zijn. Voor het verbruik in april moet dat dan ID3(Stand) - ID2(Stand) zijn... maar hoe kan dat dan eventueel? Uiteraard moet dat bv. voor een heel jaar per maand gebeuren.

Daarnaast nog een vraag:
Is het slim om de tabel op deze manier vorm te geven? Of kan ik beter gewoon de stand invoeren (zoals hierboven) maar ook een extra kolom maken met de eindstand van de vorige maand? Het kan namelijk bijv. ook gebeuren dat de gasmeter wordt vervangen en die dus weer op 0 begint. Dat gaat bij het bovenstaande een probleem opleveren lijkt me. Ik kan namelijk nergens een uitzondering invoeren waaruit blijkt dat er een nieuwe meter is geplaatst. Als ik ook de vorige stand opneem, dan kan dat denk ik wel:

Begin = beginstand van bv. 1 april,Eind = eindstand van 31 maart. Normaal gesproken hetzelfde, tenzij er een meterwissel is geweest

1 2 3 4 5 6 7 8

+----+------------+-------+-------+ | ID | Datum | Begin | Eind | +----+------------+-------+-------+ | 1 | 2011-03-01 | 23175 | 23175 | | 2 | 2011-04-01 | 23312 | 23312 | | 3 | 2011-05-01 | 0 | 23389 | | 4 | 2011-06-01 | 12 | 12 | +----+------------+-------+-------+

(Overigens kan ik ook - als de eindwaarde van de maand hetzelfde is als de startwaarde van de nieuwe maand (geen meter vervangen) - NULL (niks) invoeren, dat maakt opzich niet bar veel uit, het vraagt om een andere controle.)

Het verbruik van de vorige maand is opzich eenvoudig; een selfjoin met als voorwaarde dat de datum van de vorige meting gelijk moet zijn aan de datum van de huidige meting minus een maand.

Maar!
Een maand is geen vaste periode, het is 28,29, 30 of 31 dagen dus als je het verbruik meet in maanden, dan zal februari altijd flink minder verbruiken dan de rest van het jaar. Dus wat ga je precies rapporteren? En heb je de garantie dat je elke maand altijd een meting hebt?

Bij vervanging van een meter komt niet alleen de nieuwe meting lager uit, er zal ook een meting komen van het moment waarop de meter werd uitgeschakeld (anders moet je de meter altijd aan het eind van de maand vervangen, heb je een maandje gratis gas). In mijn beleving wordt b.v. het serienummer van de meter meegenomen in de database, zodat je A ) kunt omgaan met bedrijfspanden die vaak meerdere meters hebben en B ) kunt herkennen welke metingen bij elkaar horen. Het feit dat de meting naar nul springt kan betekenen dat er een nieuwe meter is geplaatst, maar het kan ook betekenen dat de meting niet correct is ingevoerd. In principe kan een gasmeter niet achteruitlopen dus als het serienummer van de meter hetzelfde is en de colgende meting toch lager is, dan is er iets mis.

na 9999999999 zal een mechanische meter mogelijk weer bij 0 doorgaan. Ook een uitzondering om rekening mee te houden bij je berekeningen.

je kunt iets doen met "stand nieuwe maand moet altijd groter zijn dan die van de vorige maand", maar in het geval een een afleesfout of overschrijffout, gaat dat niet op.

Gasmeters ben ik niet zo in thuis, maar oudere kWh-meters kunnen ook vrolijk achteruitdraaien, in het geval van teruglevering door een zonnepaneel oid.

@PgVincent:
Wat betreft die garantie voor metingen: ik maak het hoofdzakelijk voor mezelf om e.e.a. thuis wat beter inzichtelijk te maken. ik moet dus zelf iedere maand even de stand opnemen, dus dat komt wel goed :). Misschien gaat de familie het ook gebruiken, maar ook dan maak ik me geen zorgen over de data.

De ene maand heeft inderdaad meer dagen dan de andere. Tjah, daar doe ik op dit moment verder niks aan. Idealiter zou je (op zijn minst) per dag meten, zodat je nog een beter overzicht krijgt. Wat ik nu doe, is de vergelijking maken over de jaren heen, dus bv. maart 2011 t.o.v. maart 2010 en 2009. Dan maakt dat verschil in dagen niet zo heel veel uit.

Die vervanging van een meter gaat natuurlijk maar heel zelden voorkomen. Dat bepaalt denk ik wel even hoe ik de tabel moet vormgeven, niet de frequentie van meten (als in: die bepaalt niet de vormgeving van de tabel).

[edit: ik moet nu even een wedstrijdje sporten, ik reageer vanmiddag weer als ik thuis ben. alvast dank voor de hulp!]

Quote

Tjah, daar doe ik op dit moment verder niks aan.

Je kunt natuurlijk gewoon het gemiddelde per dag berekenen, dan maakt het niet uit hoe lang een maand is en het maakt niet uit op welke dag je de meting doet

Op 05-02-2012 12:36 schreef PgVincent www.yapf.net:

Je kunt natuurlijk gewoon het gemiddelde per dag berekenen, dan maakt het niet uit hoe lang een maand is en het maakt niet uit op welke dag je de meting doet

Dat lijkt me sowieso geen probleem nee. Prima voorstel.

Ook de optie om even een serienummer van de meter mee te loggen lijkt me een prima idee en vergt een kleine toevoeging.

@PgVincent: die self-joins ga ik eventjes nader bekijken. Als dat niet wil lukken dan hoor je /jullie het uiteraard wel.

Nu dus nog wel de vraag: hoe raden jullie aan om de 0-varianten mee te nemen in de tabel? Zowel voor het vervangen van de meter als "het klokje rond" dus.

Quote

Nu dus nog wel de vraag: hoe raden jullie aan om de 0-varianten mee te nemen in de tabel? Zowel voor het vervangen van de meter als "het klokje rond" dus.

Een beetje gasmeter loopt tot 99999 kuub, en tegenwoordig verbruikt men gemiddeld 1300 per huishouden per jaar, dus je moet een meter van dik 70 jaar oud hebben of jezelf een slag in de rondte stoken om dat geval mee te maken.

Anyhoes, Je kunt de overgang detecteren doordat het verschil tussen de vorige en de huidige metind negatief is, en dat met een marge van enkele jaarverbruiken. (dus geen invoerfoutje) Als he verschil met de vorige waarde gigantisch negatief is, dan is de nieuwe waarde het complete verbruik.

Op 05-02-2012 19:44 schreef PgVincent www.yapf.net:

Anyhoes, Je kunt de overgang detecteren doordat het verschil tussen de vorige en de huidige metind negatief is, en dat met een marge van enkele jaarverbruiken. (dus geen invoerfoutje) Als he verschil met de vorige waarde gigantisch negatief is, dan is de nieuwe waarde het complete verbruik.

Klopt in principe. Alleen wil het rare geval dat bij ons bv. laatst de watermeter vervangen is en deze niet op "0" begon te draaien (ik meen dat 'ie bij 3 m3 begon). Nu heb ik het hierboven telkens over gas, maar hetzelfde systeem is natuurlijk eenvoudig toe te passen voor water en elektra (wat overigens ook mijn bedoeling is). Nu is 3 m3 opzich niet veel als éénmalige "onnauwkeurigheid", maar het is op dit moment toch de helft van ons maandelijkse waterverbruik :).

Tsja, dan zit er maar één ding op; als de meter wordt vervangen moeten er twee aparte metingen worden gedaan om te noteren wat de eindstand van de oude meter was en wat de beginstand van de nieuwe is.

Op 06-02-2012 15:28 schreef PgVincent www.yapf.net:

Tsja, dan zit er maar één ding op; als de meter wordt vervangen moeten er twee aparte metingen worden gedaan om te noteren wat de eindstand van de oude meter was en wat de beginstand van de nieuwe is.

Dat denk ik ook ja. Die dubbele meting is verder ook niet zo'n probleem. Punt is dus alleen even of ik daarvoor gebruik maak van een extra kolom in de database om een afwijking ten opzichte van de standaard te kunnen aangeven, of dat ik dat op een andere manier oplos. Vooralsnog denk ik dat ik een kolom toevoeg, deze de standaardwaarde NULL geef (ook al is dat natuurlijk eigenlijk geen waarde) en deze wel invul als er dus een verandering van meter plaatsvindt.