[mysql/php] Opzet tabellen voor bijhouden rekeningbalans *

[Verwijderd]

Ik heb een tabel waar ik mutaties van geld per type en gebruiker bij hou. De bedoeling is dat ik per type (er zijn 8 types) geldbalansen bij houdt. Alle balansen bij elkaar (sommige negatief andere positief) zorgen voor een eindbalans. De data uit de tabel wordt tevens gebruikt voor het genereren van overzichtlijsten. De tabel is als volgt (paar niet belangrijke velden weggelaten)

id
user_id
amount
balance
type

amount = bedrag van de mutatie
balance = oude balance + nieuwe bedrag = recente balans

Nu is het dus zo dat de meest recente row van een bepaald type de meest recente balans van dit type geeft. Deze balansen van elk type wil ik querien. Nu bedacht ik me dat ik per type (er zijn er een query doen en de meeste recente row en daarmee de meest recente balans uitladen. Ik vraag me echter 2 dingen af. Aangezien ik 8 queries nodig zou hebben twijfel ik over / tussen de volgende 2 dingen:

1. Of mijn model wel goed opgezet is, ik zou bijv. ook de eindbalansen in een andere tabel kunnen updaten?
2. Of mijn model wel goed opgezet is, maar dat ik misschien met een efficiente query de 8 eindbalansen per type in enen kan uitladen?

[RobIII]

Waarom zou je uberhaupt eindbalansen opslaan? Daar hebben ze sum / group by en dat soort zaken voor uitgevonden

En wat bedoel je met uitladen

[ Voor 13% gewijzigd door RobIII op 07-05-2007 18:34 ]

[Verwijderd]

RobIII schreef op maandag 07 mei 2007 @ 18:33:
Waarom zou je uberhaupt eindbalansen opslaan? Daar hebben ze sum / group by en dat soort zaken voor uitgevonden

En wat bedoel je met uitladen

Het aantal records kan oplopen tot enkele miljoenen, waarvan enkele tienduizenden per gebruiker... Ik dacht zelf dat het uitladen van 8 records sneller zou zijn dan een sum op vrij grote hoeveelheid records. Tevens dacht ik er overover om oude mutaties in een soort geschiedenis mutatietabel op te slaan om zo het aantal records te 'beperken', maar toch nog altijd wel de juiste balans heb. Met een SUM zou ik alsnog alle records van de geschiedenis mutatietabel ook moeten meenemen.

Met uitladen bedoel ik querien, sorry voor mijn warrige termgebruik.

[ Voor 6% gewijzigd door Verwijderd op 07-05-2007 18:51 ]

[Verwijderd]

Anyone?

[Voutloos]

Dump de balance kolom, index op (userid, type) en trek het eruit in 1 efficiente query. Je moet echt véél rijen hebben voordat deze tabel met een kleine fixed length per rij uit de klauwen loopt.

Voordelen: Het scheelt queries en logica (en bug-kansen) omdat je niet steeds de redudante balans hoeft op te maken.
Nadelen: Je doet geen premature optimalisatie.

[BikkelZ]

Ik snap sowieso niet waarom er per mutatiesoort een aparte tabel moet zijn. Je maakt een tabel met mutaties en een tabel met mutatiesoorten lijkt mij. Over acht tabellen hopsen is dermate inefficient dat je alsnog beter af was met de hardcore methode.

Wat misschien nog beter is is om het uiteindelijk op user niveau bij te houden wat de balans is.

----

Wacht ff....de eindbalans op userniveau....en de tussenbalansen dan 0-8x in een tabel. Maak van user_id en balans_soort_id een primary key.

[ Voor 17% gewijzigd door BikkelZ op 09-05-2007 12:31 ]

[Verwijderd]

Voutloos schreef op woensdag 09 mei 2007 @ 08:16:
Dump de balance kolom, index op (userid, type) en trek het eruit in 1 efficiente query. Je moet echt véél rijen hebben voordat deze tabel met een kleine fixed length per rij uit de klauwen loopt.

Voordelen: Het scheelt queries en logica (en bug-kansen) omdat je niet steeds de redudante balans hoeft op te maken.
Nadelen: Je doet geen premature optimalisatie.

Oke, dus de sum methode is nog altijd de way to go blijkbaar ondanks de hoeveelheid records. Nou, heel erg bedankt allemaal, hier kan ik wel wat mee.

Had trouwens nog nooit gehoord van de term premature optimalisatie, maar na even zoeken denk ik dat het inderdaad bij mij wel aardig van toepassing is