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

Décisions SGBD Discussion :

Extraits de compte / Relevé de compte / Historique de transactions


Sujet :

Décisions SGBD

  1. #1
    Membre du Club
    Profil pro
    Inscrit en
    Mai 2003
    Messages
    50
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : Hong-Kong

    Informations forums :
    Inscription : Mai 2003
    Messages : 50
    Points : 56
    Points
    56
    Par défaut Extraits de compte / Relevé de compte / Historique de transactions
    https://fr.wikipedia.org/wiki/Relev%C3%A9_de_compte

    Bonjour,

    Pour mon client actuel je vais devoir imprimer des extraits de compte. Mon client n'est pas une banque. Ici l'idée est de pouvoir sortir un historique des factures, crédit note, débit note et paiements par client. Dans le système de base de donnée dont j'hérite il y a une table pour chacun de ces documents.

    Question: comment gérer cela au mieux. Je vois deux solutions.

    Solution 1: Ces 4 tables se suffisent à elle même et je peux facilement les mélanger dans une query qui me retourne tout l'historique des transactions trié par date. Ensuite le software est capable sans problème de calculer la balance et ce en repartant du tout début de mon historique et additionnant les facture et soustrayant les payements ligne par ligne comme une table des comptes. Facile mais à chaque nouvelle requête d'un extraite de compte, donc claque mois, je dois chaque fois tout calculer. Ça ne me choque pas.

    Solution 2: Ces 4 tables se suffisent à elle même mais je crée une table transaction qui va servir d'historique. En fait je fait la même chose que la solution 1 mais je garde mon résultat dans une table. Comme ca chaque nouveau mois je ne recalcule que le dernier moi. je dois faire moins de calcul par contre je n'ai aucune garantie de recalculer correctement mon historique si une nouvelle facture venait s'insérer ou serait supprimée au courant d'un mois précédent. Ca ne devrait pas arriver bien sur mais rien dans ma base de donné ne me contraint à cela. Et si j'ai le garantie sur papier qu'on ne peut pas supprimer, changer ou créer une facture avec une date passé je n'ai de toute façon pas cette garantie sur le paiement reçu. D'un autre côté cette solution 2 me garanti qu'une donnée tel qu'un paiement ou une facture malencontreusement supprimée n'influencera pas l'historique des transactions.

    En écrivant ces lignes j'ai envie de pencher pour la solution 2 pour me protéger. Mais ça me donne un gout amer. Je n'aime pas sauver des données que je pourrais facilement calculer.

    Des conseilles? je suis certain qu'il existe des articles entier qui expliquent comment gérer ces donnés historiques. Le même problème s'applique à la gestion de stock ainsi que de tout ce qui se gère avec des in et out / crédit débit / plus moin . Pouvez-vous m'orienter vers des lectures, blogs, etc. sur le sujet. Merci.

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 766
    Points : 52 561
    Points
    52 561
    Billets dans le blog
    5
    Par défaut
    La solution 2 est une imbécilité. En effet, les principes fondateurs des SGBD Relationnels sont :
    1) PAS DE REDONDANCE
    2) PAS DE NULL
    3) La modification sémantique d'une information ne doit pas conduire à impacter plus d'une ligne dans la base


    Votre solution 2 viole immédiatement le premier principe....

    La solution consiste à créer une vue.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. [XL-2010] Import PDF / texte relevé de comptes
    Par vinc_bilb dans le forum Macros et VBA Excel
    Réponses: 4
    Dernier message: 13/03/2015, 22h28
  2. [MySQL] Historique des transactions effectuées depuis un compte
    Par Nouveaucode dans le forum PHP & Base de données
    Réponses: 4
    Dernier message: 10/08/2013, 13h02
  3. relevé de compte banquaire
    Par chouchouboy dans le forum Requêtes et SQL.
    Réponses: 11
    Dernier message: 11/11/2007, 15h49
  4. [MySQL] relevé de compte crédit/débit
    Par stolx_10 dans le forum PHP & Base de données
    Réponses: 8
    Dernier message: 08/06/2007, 12h08
  5. [État] Relevé de Compte. Comment faire ?
    Par nicou50 dans le forum IHM
    Réponses: 19
    Dernier message: 26/03/2007, 05h30

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