[DB] 3NV hierop toepassen of juist niet?

[SH4D3H]

Ik heb een soort van probleem mbt tot het ontwerp van wat tabellen en wilde weten wat jullie mening hierover is.
Ik leg het wel even uit aan de hand van een verhaaltje:
Ik wil mensen laten inloggen op mijn applicatie, daarvoor is een gebruikersnaam, wachtwoord en een contacte-mailadres nodig voor eventuele wachtwoord-recovery.

code:

gebruikersnaam
wachtwoord
email

Maar nu wil ik m’n gebruikers wat beter leren kennen en wil personalia opslaan.
Dus naam, adres, etc komt erbij, in dezelfde tabel lijkt me, iemand heeft maar 1 naam tenslotte

code:

gebruikersnaam
wachtwoord
email
voornaam
achternaam
geboortedatum
adres # postcode etc, eigenlijk aparte rows maar dat is niet relevant nu

Nog later wil ik dat mijn gebruikers geld kunnen storten op hun account en moet ik een saldo bijhouden. Dan komt het probleem: volgens 3NV moeten procesgegevens niet in een tabel.
Dus het saldo wordt nergens opgeslagen, dat is immers de inkomsten min de uitgaven.
Maar wat als iemand, of iedereen, heel veel transacties gaat doen?
Dan moet ik elke keer, misschien wel meerdere keren per seconde, tientallen of wie weet duizenden records optellen en aftrekken om aan het saldo te komen.
Kan ik dan beter een aparte tabel maken, hoewel er dan een 1 op 1 relatie is bijv:

code:

gebruiker
saldo
inkomsten
uitgaven

Hoewel je die tabel dan flink moet updaten elke keer EN er een 1 op 1 relatie ontstaat omdat iedereen maar 1 saldo kan hebben. En in de meeste gevallen wordt er gezegt dat een 1 op 1 relatie duidt op een slecht DB ontwerp.
Ik kan dat ook in de eerste tabel zetten.

Zouden jullie gewoon blijven rekenen of toch ‘stiekum’ makkelijk ergens anders opslaan?
Want stel ik wil weten wie de rijkste is, gaat dat niet enorm veel rekenwerk kosten?

[EfBe]

Waarom zou Saldo niet bij user in de tabel kunnen? De relatie tussen attribute 'saldo' en de attribute gebruikersnaam is 1:1, of heeft een gebruiker meerdere saldi?

Bij 1:n relaties tussen attributes, moet je inderdaad een andere table maken.

[whoami]

Sommige dingen kan je best denormaliseren als het werkelijk veel tijd kost om die berekening te gaan doen. (Bijvoorbeeld het bijhouden van de postcount op een forum).
Dan moet je je er ook bewust van zijn, dat je er zeker moet van zijn dat die waarde t.a.t. correct is. Als je saldo door één of andere bug niet correct is opgeslagen, dan kan dat heel wat problematischer zijn dan als je postcount op een of ander forum er 10 of 50 posts naast zit.

De vraag die je je moet stellen: is het werkelijk zo'n zware berekening om dat saldo iedere keer opnieuw te gaan bepalen ? Dit zal je dan eens moeten nagaan.
(Je spreekt trouwens over 'nog later'. Moet je er dan nu al rekening mee gaan houden vraag ik me af ? Het lijkt me niet dat je dat nu al in je datamodel moet voorzien ? ).

[SH4D3H]

EfBe schreef op zondag 07 januari 2007 @ 12:16:
Waarom zou Saldo niet bij user in de tabel kunnen?

Saldo is volgens 3NV een procesgegeven ( namelijk wat de persoon gestort heeft min wat de persoon uitgegeven heeft ) en zou er daarom niet in mogen, dacht ik iig.

De relatie tussen attribute 'saldo' en de attribute gebruikersnaam is 1:1, of heeft een gebruiker meerdere saldi?

Nee, maar het ging dus om wat ik hierboven zei.

whoami schreef op zondag 07 januari 2007 @ 12:17:
Dan moet je je er ook bewust van zijn, dat je er zeker moet van zijn dat die waarde t.a.t. correct is.

Dat is idd iets waar ik niet direct aan gedacht heb.

De vraag die je je moet stellen: is het werkelijk zo'n zware berekening om dat saldo iedere keer opnieuw te gaan bepalen ? Dit zal je dan eens moeten nagaan.

Ik ben niet geweldig thuis in de snelheid van een database.
Maar een serie stortingen optellen en uitgaven aftrekken met SUM() - SUM() kan best zwaar worden met veel rows?
Of denk ik dan te licht over de DB?
( Zolang ik geen eigen server heb, zal ik sowieso op de load moeten letten. )

(Je spreekt trouwens over 'nog later'. Moet je er dan nu al rekening mee gaan houden vraag ik me af ? Het lijkt me niet dat je dat nu al in je datamodel moet voorzien ? ).

Niet?
Het lijkt mij niet de bedoeling dat ik elke x weken mijn datamodel moet herzien omdat er meer gebruikers zijn bijgekomen of dat er iets anders verandert is.
Is het niet handig om vanaf het begin al 'overal' op voorbereid te zijn zodat het zonder al te veel onderhoud gewoon blijft lopen?

[Remus]

Het saldo is geen procesgegeven in mijn ogen, maar een weergave van de huidige stand van zaken (hoeveel iemand aan tegoed heeft). Zeker met belangrijke informatie als een saldo lijkt het mij belangrijk om die informatie in de database op te slaan en niet continu te berekenen.

Inkomsten en uitgaven zijn wel IMHO wel procesgegevens.

SH4D3H schreef op zondag 07 januari 2007 @ 13:08:
Niet?
Het lijkt mij niet de bedoeling dat ik elke x weken mijn datamodel moet herzien omdat er meer gebruikers zijn bijgekomen of dat er iets anders verandert is.
Is het niet handig om vanaf het begin al 'overal' op voorbereid te zijn zodat het zonder al te veel onderhoud gewoon blijft lopen?

Nu al rekening houden met zaken die in de toekomst mogelijk nodig gaan zijn is tijdverspilling. Voortschrijdend inzicht in het probleemdomein of de daadwerkelijk gewenste functionaliteit zullen er bijna altijd voor zorgen dat de uiteindelijke implementatie anders is dan je van te voren verwachte, waardoor je voorwerk dus overbodig en misschien zelfs hinderlijk is geworden. Hinderlijk, omdat het eerder gemaakte ontwerp je een vooringenomen blik geeft op wat echt nodig is.

[ Voor 56% gewijzigd door Remus op 07-01-2007 13:34 ]

[SH4D3H]

Bedankt, ik kom er wel uit nu (hoop ik )

[RobIII]

SH4D3H schreef op zondag 07 januari 2007 @ 13:08:
Saldo is volgens 3NV een procesgegeven ( namelijk wat de persoon gestort heeft min wat de persoon uitgegeven heeft ) en zou er daarom niet in mogen, dacht ik iig.

En dat is nu zo'n mooi gevalletje wanneer je afwijkt (beter: kunt afwijken) van wat je op school hebt geleerd; het hoeft niet altijd "by the book", de praktijk is soms heel anders dan de theorie.

Remus schreef op zondag 07 januari 2007 @ 13:29:
Het saldo is geen procesgegeven in mijn ogen, maar een weergave van de huidige stand van zaken (hoeveel iemand aan tegoed heeft). Zeker met belangrijke informatie als een saldo lijkt het mij belangrijk om die informatie in de database op te slaan en niet continu te berekenen.

Zeker met belangrijke informatie als een saldo lijkt het mij belangrijk om die informatie juist wel te berekenen. Er hoeft maar 1 keer iets mis te gaan bij het updaten van het saldo en je saldo komt niet meer overeen met de inkomsten/uitgaven.

Zo zwart-wit is het niet altijd; TS zal zelf een afweging moeten maken wat het makkelijkst beste is. Gaat het over vele miljoenen records dan kan het de moeite zijn om het saldo apart bij te houden en (bijv. m.b.h.v transtacties) te zorgen dat het saldo gewoon t.a.t. klopt. Gaat het over een paar honderd users met een paar honderd "inkomsten/uitgaven" dan kun je het waarschijnlijk net zo goed ter plekke berekenen (of beter: bouw een view). wiebenik slaat dan ook IMHO de spijker op z'n kop:

whoami schreef op zondag 07 januari 2007 @ 12:17:
De vraag die je je moet stellen: is het werkelijk zo'n zware berekening om dat saldo iedere keer opnieuw te gaan bepalen ? Dit zal je dan eens moeten nagaan.

[ Voor 10% gewijzigd door RobIII op 07-01-2007 18:46 ]

[SH4D3H]

RobIII schreef op zondag 07 januari 2007 @ 18:37:
Zo zwart-wit is het niet altijd; TS zal zelf een afweging moeten maken wat het makkelijkst beste is. Gaat het over vele miljoenen records dan kan het de moeite zijn om het saldo apart bij te houden en (bijv. m.b.h.v transtacties) te zorgen dat het saldo gewoon t.a.t. klopt. Gaat het over een paar honderd users met een paar honderd "inkomsten/uitgaven" dan kun je het waarschijnlijk net zo goed ter plekke berekenen (of beter: bouw een view). wiebenik slaat dan ook IMHO de spijker op z'n kop:

Ik denk dat ik het dan eerst gewoon 'live' ga berekenen.
Mocht de load te zwaar worden voeg ik gewoon het veld 'saldo' toe en laat het vullen.
Zo'n zware ingreep is dat ook weer niet als ik niets aan de API verander

[Robbemans]

Dit soort problemen kun je ook met een periode-berekening oplossen. Bij elke mutatie hou je het tijdstip vast, waarna je je saldo periodiek kunt bijwerken tot een bepaalde datum. Hiermee heb je altijd een berekening over een korte periode. Mocht je saldo scheef gaan lopen door een bug, dan kun je je hele saldo opnieuw laten berekenen.