Bonjour à tout le monde,

Je me retrouver pour le première fois à faire une base de donnée de produit à vendre, d'utilisateur et de facture.
J'utilise MySQL.

Voici mon problème :
L'utilisateur 4, qui habite Lyon passe une commande du produit 8 en 3 expemplaire, qui est 7.95€. (Vous voyez surement où je vais en venir). Créer une facture est donc tout simple :
facture.id : 1
facture.user : 4
produit_facture.produit_id : 8
produit_facture.produit_quantity : 3

Demain, le prix de mon produit vient à changer, mon client déménage, comment je fais pour retrouver les données de la facture passée.
La seule solution que je vois est de tout mettre en brute dans les table facture et produit_facture, mais ma BDD va vite devenir énorme.

Merci d'avance

Pour le prix, le contrat fixe le prix de vente. Donc, pas de soucis pour le changer une fois le contrat passé.

Pour le déménagement, quand le client contacte une société, celle-ci va en profiter pour mettre à jour les coordonnées du client, et de plus, il doit y avoir une loi qui oblige le client à mettre à jour ses coordonnées dès que possible. Donc, tu ne devrais jamais avoir 2 adresses d'un même client.

CristianoRolando a écrit:

Pour le prix, le contrat fixe le prix de vente. Donc, pas de soucis pour le changer une fois le contrat passé.

Pour le déménagement, quand le client contacte une société, celle-ci va en profiter pour mettre à jour les coordonnées du client, et de plus, il doit y avoir une loi qui oblige le client à mettre à jour ses coordonnées dès que possible. Donc, tu ne devrais jamais avoir 2 adresses d'un même client.

Bonjour @CristianoRolando tout d'abord, merci pour ton aide.

J'en fait, j'envisage les tables suivante :
- produit
- commande
- produit_commande
- client

La table commande contient 3 champs (et un id) :
- numero
- client_id
- date

La table produit_commande contient 2 champs (et un id) :
- commande_id
- produit_id
- qte

Mon souci est le suivant, si un client reviens dans 3 semaine et me demande la facture, si le prix d'un des produit_id de la commande a changé, sa facture ne sera pas bonne, le prix dessus n'étant pas celui qu'il a acheté il y a 3 semaines.
Même soucis pour un déménagement. Le fait que le client ait déménagé, je le met à jour dans la base, mais je ne veux pas que sa nouvelle adresse figure sur la facture qu'il a perdu.

La seule solution que je vois est de tout mettre en brute dans mes tables de commande, mais cela me parait lourd, je voulais savoir si il existait des solutions autre.
Je me dit aussi de faire une table client_adresse avec la date de l'adresse, pareil pou les prix, prix_produit ou je stock, pour ces deux tables les dates. Ce qui me permettrait de trouver le prix d'un produit à une date X.

Si quelqu'un connais la bonne pratique, merci d'avance

-
Edité par Thibault.Martin34 15 août 2023 à 7:43:08

C'est une simu ou tu as vraiment un commerce ?

Ca fait longtemps que j'ai lâché le droit. Mais, je répète ma première réponse. Tu vends des carottes à 50 € le kilo le 16 août. Ton acheteur demande la facture 20 jours après, le montant sera de 50 € le kilo, peu importe le prix des carottes le 5 septembre prochain.

Si tu es un intermédiaire, tu pourrais faire le malin, mais si tu te fais chopper ça puera pour toi, en facturant jour j, commandant jour j+10 en espérant une baisse du prix donc une plus grosse marge, mais c'est risqué.

Et pour les adresses, pour quelle raison tu veux geler l'adresse de facturation ? À part pour des stats, je vois pas.

Pour te répondre techniquement, de tête, pourquoi ne pas ajouter un champ (à éclater car une adresse ça s'éclate dans une BDD) pour l'adresse précédente et de NULLABLE l'adresse suivante.

Dans le pire cas où un acheteur a la bougeotte, tu fais une relation CLIENT 1,N vivre à (#Client, #adresse) 1,N ADRESSE

Bonjour,

Merci encore pour le temps que tu m'accorde.

Mon cas n'est pas simulation et se présente vraiment.

CristianoRolando a écrit:

Tu vends des carottes à 50 € le kilo le 16 août. Ton acheteur demande la facture 20 jours après, le montant sera de 50 € le kilo, peu importe le prix des carottes le 5 septembre prochain.

C'est bien là qu'est mon problème. A l'école, j'ai appris :

Ma table ligne_commande référence un id de produit. Si demain son nom ou son prix change, si je ressort une facture d'avant ce changement, le prix sera pas bon, le mon non plus, une éventuelle descriptions dans la table produit. Il en va de même pour la ville.

J'ai simplifié ma base de donnée ici, en retirant plusieurs champ. Mais du coup, je ne dois avoir aucun lien relationnel pour les tables commande et ligne_commande, comme ci-dessous ?

* Quand j'utilise base.champ, c'est qu'il y a derrière une règle relaationnel

-
Edité par Thibault.Martin34 16 août 2023 à 14:44:54

ok

alors ce que je ferais en cas de changement de prix :

Produit, je retire le prix.

Ajout de la table Prix avec : #produit, date début, date fin (NULLABLE si inconnue), prix

Ainsi tu feras un Read avec la date de la commande correspondant à la bonne ligne de Prix.

Je peux pas tester, mon ordi se repose l'été, il est vieux et craint la chaleur.

Quand on a un doute, la première idée est d'imaginer une relation N et donc créer des tables relationnelles. Mais, est-ce que ça vaut le coût (sic) ?

j'ai trouvé cet article de SQLPRO https://sqlpro.developpez.com/cours/modelisation/metadonnees/

Je te conseille de le suivre (le gars), il a dû tomber dans la marmitte des BDD, c'est un expert 

-
Edité par CristianoRolando 17 août 2023 à 1:56:01

Bonjour,

Je re remercie pour ton retour et je met donc mon sujet en résolu

ok

quelle solution tu as choisie ?

Hello,

Soit tu stock en dur les valeurs au moment de la création de la facture, soit tu gères un historique des prix (ou des adresses)

Bonjour à tous,

Ayant vraiment beaucoup de données jointes, j'ai choisi de les stocker en dur dans la facture.