1. #1
    Nouveau membre du Club
    Inscrit en
    janvier 2010
    Messages
    39
    Détails du profil
    Informations forums :
    Inscription : janvier 2010
    Messages : 39
    Points : 25
    Points
    25

    Par défaut Optimiser une BDD dépense/catégorie dépense

    Bonjour,

    Je souhaiterai avoir des avis pour l'optimisation d'une base de donnée pour la gestion des comptes.
    J'ai pour idée de séparer les dépenses de leur catégories associées dans deux tables différentes.
    Je m'explique,

    Admettons une dépense de 100 euros par carte dans une grande surface, concernant des produits de différentes catégories.
    Mon idée est donc de renseigner la dépense dans la table "Dépense", et les catégories dans la table "CatégorieDepense".

    Table Dépense
    ID Type Montant Commercant
    30 Carte 100euros ChezLeclerc

    Table Catégorie dépense
    ID Id dépense Catégorie Montant
    40 30 Course 50
    41 30 Electro 50


    Je vois bien l’intérêt pour une dépense admettant plusieurs catégories, mais si cette dernière n'est liée qu'à une seule j'ai un doute sur l'optimisation des tables.
    En effet l'information serai reprise 2 fois comme ci-dessous.

    ID Type Montant Commercant
    30 Carte 100euros ChezLeclerc

    Table Catégorie dépense
    ID Id dépense Catégorie Montant
    40 30 Course 100

    Si quelqu'un pourrai me donner son avis?

    Par avance merci.

  2. #2
    Expert éminent Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    février 2011
    Messages
    2 918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 77
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : février 2011
    Messages : 2 918
    Points : 8 589
    Points
    8 589

    Par défaut

    Sakut schmitx.

    Vous avez trois tables, dont deux sont des tables mère (table dépense et table catégorie) et une, une table fille (table dépense_catégorie).
    Votre table fille est aussi une table associative, car elle a deux mères.
    La table fille possède aussi une clef étrangère vers la table dépense et une autre clef étrangère vers la table catégorie.
    Vous devez insérer en premier vos lignes dans les tables mère (table dépense et table catégorie) avant de faire vos insertions dans la table fille (table dépense_catégorie).
    L'organisation est correcte et je ne voie pas trop ce que vous désirez améliorer.

    Vous ne savez pas à l'avance si les dépenses occasionnées vont produire 1 ou plusieurs lignes de d'achats.
    Donc votre base de données s'adapte parfaitement à cette contrainte.
    Alors en quoi cela vous pose un problème ?

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  3. #3
    Nouveau membre du Club
    Inscrit en
    janvier 2010
    Messages
    39
    Détails du profil
    Informations forums :
    Inscription : janvier 2010
    Messages : 39
    Points : 25
    Points
    25

    Par défaut

    Bonjour,
    Merci pour votre réponse. Je voulais simplement avoir un avis sur ma logique avant de me lancer. Puisque tout va s'articuler autour de ces tables.
    Pour le coup je suis rassuré et vais pouvoir construire mon programme.

  4. #4
    Expert éminent Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    février 2011
    Messages
    2 918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 77
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : février 2011
    Messages : 2 918
    Points : 8 589
    Points
    8 589

    Par défaut

    Salut schmitx.

    Je suppose que les libellés de la catégorie sont bien "course", "electro".
    Et donc, il ne faut pas les mettre dans la table "dépense_catégorie", mais dans catégorie.
    Cela évite une répétition inutile qui va consommer de l'espace disque pour rien.

    Les seules informations que vous devez mettre dans la table associatives "dépense_catégorie" concerne à la fois celle de dépense et de catégorie.
    Le libellé est une information de la table catégorie et ne doit pas être présente dans la table "dépense_catégorie".

    La colonne "ID" de la table "dépense_catégorie" (celle en majuscule) n'a pas de raison d'être car le couple (identifiant dépense, identifiant catégorie) est unique.
    Et donc, l'identifiant de la table est ce couple.
    Il n'y a aucune raison d'avoir plusieurs fois la catégorie pour une dépense donnée.
    Si c'est le cas alors introduisez la quantité. Le prix est alors le prix unitaire.

    Vous devez avoir toujours à l'esprit les formes normales quand vous concevez une base de données.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  5. #5
    Nouveau membre du Club
    Inscrit en
    janvier 2010
    Messages
    39
    Détails du profil
    Informations forums :
    Inscription : janvier 2010
    Messages : 39
    Points : 25
    Points
    25

    Par défaut

    D'accord je vais étudier celà,
    Merci pour l'astuce du couple d'identifiant unique.
    Je vais continuer sur cette voie.

  6. #6
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 996
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 996
    Points : 6 582
    Points
    6 582
    Billets dans le blog
    1

    Par défaut

    Citer les formes normales c'est bien, les appliquer c'est mieux

    Votre modèle de données n'est pas correct pour plusieurs raisons :

    • il ne faut jamais stocker des montants calculés, car c'est à la fois une redondance et un risque d'incohérence.
      ==> si vos 100 € d'achats correspondent à 50€ de courses + 50€ d'éléctro-ménager, vous devez ne stocker que ces deux lignes détail, et calculer la somme si besoin par une fonction SQL :
      select sum(montant) from...
      Eventuellement, vous pourrez créer une vue qui fait cette requête.
    • il faut externaliser les typologies dans des tables dédiées (type de dépense, code devise, moyen de paiement, etc...)
    • il ne faut pas utiliser des libellés mais des identifiants "clefs étrangères" faisant référence aux tables de typologie
    • qui dit suivi des dépenses, dit datage (voire horodatage) de ces dépenses. De plus, l'ajout d'un code devise est recommandé
    • vous n'identifiez pas clairement le commerçant, "chez leclerc" c'est bien mais si vous fréquentez plusieurs établissement de cette enseigne, c'est insuffisant, une entité-type "commerçant" serait préférable
    • de même, vous n'identifiez pas le porteur de la dépense, je suppose donc que vous ne voulez gérer que vos propres dépenses qui ne concernent qu'un seul compte
      Si vous voulez pouvoir gérer plusieurs comptes, il faut bien évidemment enrichir le modèle pour associer le porteur à chaque ligne de dépense
    • le moyen de paiement (carte, chèque, espèces...) ne vous intéresse-t-il pas

  7. #7
    Nouveau membre du Club
    Inscrit en
    janvier 2010
    Messages
    39
    Détails du profil
    Informations forums :
    Inscription : janvier 2010
    Messages : 39
    Points : 25
    Points
    25

    Par défaut

    Bonjour,

    Le modèle de table que j'ai présenté était simplifié.
    J'identifie en effet la personne (au travers de son ID de compte bancaire), le type de paiement et récupère la date du paiement. Mais je ne voulais pas encombrer l'exemple pour rester focaliser sur la gestion des dépenses et de leurs catégories associées.
    Par contre je n'ai pas précisé la devise...je vais y penser.

    il ne faut jamais stocker des montants calculés, car c'est à la fois une redondance et un risque d'incohérence.
    ==> si vos 100 € d'achats correspondent à 50€ de courses + 50€ d'éléctro-ménager, vous devez ne stocker que ces deux lignes détail, et calculer la somme si besoin par une fonction SQL :
    select sum(montant) from...
    Peux tu me donner un exemple avec les champs de la table approprié?
    Si je ne stocke que ces deux lignes comment les identifier pour une même dépense?

    Pour le champs type de paiement, je n'ai fait qu'une simple liste déroulante (carte,liquide,chèque,virement) sans lier une table dédiée.

  8. #8
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 996
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 996
    Points : 6 582
    Points
    6 582
    Billets dans le blog
    1

    Par défaut

    En fait tout dépend de votre expression de besoin, mais il est probable que vous deviez stocker non pas les dépenses par catégorie (éléctro-ménager, nourriture, vétements...) mais au plus fin c'est à dire par article, chaque article ayant une catégorie ce qui vous permettra de regrouper sur la catégorie et sur l'achat dans sa globalité (c'est à dire la somme des dépenses d'un client chez un commerçant à un instant "t")

    Conceptuellement, vous pouvez modéliser comme dans le cas d'une gestion par commande client, même si vous ne passez pas par une commande stricto sensu, car cette modélisation permet de lier le client au commerçant via la commande et ses lignes de commandes qui référencent les articles, articles qui appartiennent à des catégories.

  9. #9
    Nouveau membre du Club
    Inscrit en
    janvier 2010
    Messages
    39
    Détails du profil
    Informations forums :
    Inscription : janvier 2010
    Messages : 39
    Points : 25
    Points
    25

    Par défaut

    D'accord.
    En fait je n'ai pas à gérer des commandes ou code article.
    C'est une base de donnée gérant les dépenses du quotidien rien de bien difficile en soi, mais par la suite j'y rajouterai des modules la rendant plus complexe. D'où l'idée quelle soit bien modélisée.

Discussions similaires

  1. comment optimiser la connexion dans une BdD
    Par ouadie99 dans le forum Accès aux données
    Réponses: 1
    Dernier message: 12/03/2008, 13h04
  2. Optimiser une BDD
    Par zanou666 dans le forum IHM
    Réponses: 3
    Dernier message: 22/10/2007, 16h44
  3. Réponses: 2
    Dernier message: 22/09/2006, 10h29
  4. Debutant: Optimisation d'une bdd !
    Par [DreaMs] dans le forum Débuter
    Réponses: 2
    Dernier message: 07/07/2006, 06h16
  5. [Optimisation]Comment proceder pour une BDD très importante?
    Par XTopheBde dans le forum Décisions SGBD
    Réponses: 8
    Dernier message: 04/01/2006, 14h10

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