Discussion :

[schmitx]

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.

[Artemus24]

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 ?

@+

[schmitx]

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.

[Artemus24]

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.

@+

[schmitx]

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

[escartefigue]

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
  

[schmitx]

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.

[escartefigue]

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.

[schmitx]

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.