IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Gestion de comptes bancaires. [Modèle Relationnel]


Sujet :

Schéma

  1. #1
    En attente de confirmation mail
    Profil pro
    Inscrit en
    novembre 2003
    Messages
    82
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : novembre 2003
    Messages : 82
    Points : 78
    Points
    78
    Par défaut Gestion de comptes bancaires.
    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à?

  2. #2
    Inactif   Avatar de Médiat
    Inscrit en
    décembre 2003
    Messages
    1 946
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 1 946
    Points : 2 225
    Points
    2 225
    Par défaut
    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..
    J'affirme péremptoirement que toute affirmation péremptoire est fausse
    5ième élément : barde-prince des figures de style, duc de la synecdoque
    Je ne réponds jamais aux questions techniques par MP

  3. #3
    En attente de confirmation mail
    Profil pro
    Inscrit en
    novembre 2003
    Messages
    82
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : novembre 2003
    Messages : 82
    Points : 78
    Points
    78
    Par défaut
    Citation Envoyé par pgibone
    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.

    Citation Envoyé par pgibone
    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.

    Citation Envoyé par pgibone
    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

  4. #4
    Membre confirmé

    Profil pro
    Inscrit en
    janvier 2003
    Messages
    113
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2003
    Messages : 113
    Points : 480
    Points
    480
    Par défaut
    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...
    Ce que l'on conçoit bien s'énonce clairement,
    Et les mots pour le dire arrivent aisément.
    L'Art poétique - Nicolas Boileau (1636-1711)

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 10
    Dernier message: 26/11/2010, 08h50
  2. Gestion de comptes bancaires sous C++
    Par abdeljaouad dans le forum C++
    Réponses: 11
    Dernier message: 22/05/2009, 20h34
  3. [MySQL] Gestion de compte (bancaire par exemple)
    Par jmtrivia dans le forum PHP & Base de données
    Réponses: 3
    Dernier message: 16/04/2009, 23h13
  4. [MCD]Gestion de comptes bancaires
    Par Sandriiine dans le forum Schéma
    Réponses: 10
    Dernier message: 22/05/2008, 14h50
  5. Gestion de comptes bancaires
    Par Franck.H dans le forum Applications et environnements graphiques
    Réponses: 7
    Dernier message: 02/11/2007, 09h06

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo