Discussion :

[Elmilouse]

Dans une base de données trés simple, je voudrais gerer des comptes bancaires. J'ai donc pensé à deux entités : Compte et Operation. Une operation est soit une sortie, soit une entrée d'argent dans un compte.
J'ai un probleme au niveau des soldes des comptes. J'ai deux possibilités :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
1 :
Compte(IdCompte,Nom,Solde)
Operation(IdOperation,Libéllé,Montant,IdCompte)

ou

2 :
Compte(IdCompte,Nom)
Operation(IdOperation,Libéllé,Montant,IdCompte)

dans le cas 1, il faut qu'à chaque nouvelle operation entrée ,modifier le solde du compte concerné.
dans le cas 2, pour connaitre le solde actuel d'un compte faire une requete Sum sur les operations qui concernent ce compte.

Ma question est : quelle est la meilleure solution (etonnant comme question ) , ou existe-t-il une troisieme solution meilleure que ces deux là?

[Médiat]

Personnellement je n'aime pas stocker des valeurs calculables (même si l'utilisation de trigger réduit les risques d'incohérence), j'aurais donc tendance à privilégier la solution 2 (ce que j'ai fait pour gérer mes comptes perso et j'ai 10 ans d'historique, sans problème de performance) ; il va de soi que suivant le nombre d'enregistrements, et pour des raisons de performance, la solution 1 peut se comprendre.
Une troisième solution serait de stocker une "situation de fin d'année", afin de n'avoir plus qu'à totaliser les mouvements de l'année + la situation en fin d'année précédente (avantage : cette situation en fin d'année n'évolue pas, et permet de faire du nettoyage dans la base).
C'est un peu simpliste, mais pour décrire complètement une solution, il faudrait avoir une description complète du problème : Nombre de clients, de mouvements, statistiques envisagées sur un an , 2 ans, 10 ans... etc..

[Elmilouse]

Personnellement je n'aime pas stocker des valeurs calculables (même si l'utilisation de trigger réduit les risques d'incohérence)

c'est ce que je pense aussi; en fait, j'avais pensé à la premiere solution mais ca me plaisait pas donc j'ai pensé à la deuxieme.

il va de soi que suivant le nombre d'enregistrements, et pour des raisons de performance, la solution 1 peut se comprendre.

C'est pour cette raison que je demande votre avis, la deuxieme solution me gene un (tout petit) peu, car pour avoir une simple information (le solde d'un compte), il faut faire une requete assez importante.

Une troisième solution serait de stocker une "situation de fin d'année", afin de n'avoir plus qu'à totaliser les mouvements de l'année + la situation en fin d'année précédente (avantage : cette situation en fin d'année n'évolue pas, et permet de faire du nettoyage dans la base).
C'est un peu simpliste, mais pour décrire complètement une solution, il faudrait avoir une description complète du problème : Nombre de clients, de mouvements, statistiques envisagées sur un an , 2 ans, 10 ans... etc..

Je suis dans le meme cas que toi, c'est aussi pour une utilisation personnelle; donc peu d'informations stockées, peu de mouvements... d'après ton avis, je pense donc que je vais opter pour la deuxieme solution.
Merci beaucoup de m'avoir donné ton avis

[Nanci]

C'est toute la problématique de l'équilibre entre
- la redondance en mémorisant un attribut calculé (ici le solde)
- la performance (temps de recalcul du solde).

Je peux simplement témoigner que dans le cas des banques, le solde (daté) est calculé (en batch nocturne) uniquement en ne prenant les mouvements passés depuis la dernière date de calcul.

Au niveau de la table Compte (pour simplifier...), il ya a donc deux attributs: solde, au
La rapidité de réponse à une consultation de solde prime sur l'exactitude du solde: les mouvements du jour ne sont pas pris en compte
Par contre, les banques lancent le calcul de solde (presque) tous les jours.

En conclusion
- pour une application perso, il vaut mieux recalculer le solde à chaque consultation
- pour une appli pro, faire comme les banques...