Discussion :

[superthx]

Bonjour,

J'ai beau essayé de me creuser la tete mais rien ni fait.

J'ai une table Produits, incluant le prix et la date du prix.
Et je ne sais pas comment creer dans une autre table un historique du produit et du prix.

C'est a dire que si le prix est de 1€ le 01/01/2012.
Et que le prix change de 2€ le 02/02/2012.

Qu'il ne registre le dans un historique les changement de prix.

Comment mi prendre ?

Merci.

[BILANGA]

Bonjour superthx,

Je pense que c'est une solution. Dans la table historique il faut mettre un champs avec incrementation automatique.

[RobiPMS]

Bonjour.
Je suppose que tu as un formulaire (F_Produits) qui te permet d'afficher le contenu de ta table Produits, et d'encoder les infos les concernant.
Tu dois aussi avoir un identifiant pour chaque produit (un champ nommé Id_produit, par exemple).
Ta table Historique_prix (je ne sais pas comment tu la nommes) devrait au moins comporter un champ Id_produit (avec une relation entre les champs Id_produit des deux tables) et les champs Prix et Date_du_prix. Si tu as tout ça, une solution simple serait de :
1. dans les propriétés des champs Prix et Date_du_prix du formulaire "F_Produits", mettre "verrouillé" sur Oui.
2. Créer une requête ajout dont l'exécution créera un nouvel enregistrement dans la table Historique_prix, avec l'ID_produit actuellement affiché dans le formulaire F_Produits, le prix et la date.
3. Créer un bouton qui va d'abord exécuter la requête Ajout, puis permettre l'encodage des nouveaux prix et date du prix en déverrouillant les champs.
Ainsi, dans la table historique, tu auras toujours les prix antérieurs au prix actuel, et le fait d'obliger à déverrouiller pour encoder un nouveau prix fait qu'il sera impossible d'encoder un nouveau prix sans que l'ancien soit sauvegardé.
Cordialement.

[superthx]

Ok, je vois la dermarche.
Je vais tester cela cet aprem.
Merci

[Richard_35]

Bonjour à tous,

Je me permets de m'immiscer RobiPMS, désolé...

Il me semble que la structure des tables doit être revue.

Structure actuelle (souligné=clé primaire, #=clé étrangère) :

Produit(IdProduit, Libellé, DatePrix, Prix, ...).

mais, Superthx, tu es ennuyé de perdre l'ancien prix quand celui-ci change, ce qui t'amène, à raison, à créer une table Historique. Dans ce cas, attention à la redondance des données. Il serait judicieux de migrer vers cette structure :

Produit(IdProduit, Libellé, DatePrix, Prix, ...) ;
HistoProduit(IdProduit, DatePrix, Prix, ...).
==> le dernier prix étant retrouvé via une requête Max(DatePrix) ==> Prix.

[RobiPMS]

Bonjour Richard_35.
Pas de souci pour l'immixtion!
Juste une réflexion : éviter la redondance des données sert à éviter que la même info soir reproduite à différents endroits, à limiter l'espace disque nécessaire, à limiter le risque d'incohérence lié aux multiples écritures, et à éviter les processus de mise à jour. Dans ce cas-ci, la structure proposée est telle que la même information ne figure qu'à un seul endroit : le prix actuel dans la table des produits et les anciens prix, avec la date, dans la table historique. C'est juste en quelque sorte un archivage des anciens prix.
A priori, je ne vois pas ce que l'on gagnera à supprimer le prix actuel de la table des produits.
Mais peut-être y a-t-il une raison que je ne perçois pas : y a-t-il un risque concret à laisser un champ prix dans la table des produits?
C'est en se posant des questions qu'on progresse!
Cordialement,

[Richard_35]

Re-bonjour RobiPMS,

Tout est dans :

le prix actuel dans la table des produits et les anciens prix

==> nous parlons donc toujours d'un couple Date/Prix :

• prix actuel : prix dont la date du jour est > ou = à la date du dernier prix ;
• prix anciens : prix dont la date est < à la date du dernier prix.

Donc, la notion de couple Date/prix est à deux endroits différents : conceptuellement, cela posera des soucis. La preuve en est, entre autres, qu'il faut programmer en tenant compte de ces deux endroits (champs verrouillés, par exemple).

[superthx]

Bonjour à tous,

Je me permets de m'immiscer RobiPMS, désolé...

Il me semble que la structure des tables doit être revue.

Structure actuelle (souligné=clé primaire, #=clé étrangère) :

Produit(IdProduit, Libellé, DatePrix, Prix, ...).

mais, Superthx, tu es ennuyé de perdre l'ancien prix quand celui-ci change, ce qui t'amène, à raison, à créer une table Historique. Dans ce cas, attention à la redondance des données. Il serait judicieux de migrer vers cette structure :

Produit(IdProduit, Libellé, DatePrix, Prix, ...) ;
HistoProduit(IdProduit, DatePrix, Prix, ...).
==> le dernier prix étant retrouvé via une requête Max(DatePrix) ==> Prix.

Merci je vais utiliser cette demarche. Je la vois simple de mettre en place

[f-leb]

bonsoir,

[Résolu] mais quand même

Donc, la notion de couple Date/prix est à deux endroits différents : conceptuellement, cela posera des soucis. La preuve en est, entre autres, qu'il faut programmer en tenant compte de ces deux endroits (champs verrouillés, par exemple).

En fait j'irais plutôt dans le sens de RobiPMS car je ne vois aucun problème conceptuel ou redondance à séparer les prix actuels des anciens prix.

Produit(idproduit, NomProduit, DateMAJPrix, PrixEnCours)

HistoPrixProduit(#idProduit, DateDebut, DateFin, PrixHisto)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Produit:
idProduit    ...    DateMAJPrix     PrixEnCours
1                   01/02/2012      100.00

HistoPrixProduit:
idProduit     DateDebut      DateFin          PrixHisto
1             01/01/2012     31/01/2012       90.00
1             01/07/2011     31/12/2011       88.00
1             01/01/2011     30/06/2011       85.00

Si changement de prix demain...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Produit:
idProduit    ...    DateMAJPrix     PrixEnCours
1                   29/02/2012      110.00

HistoPrixProduit:
idProduit     DateDebut      DateFin          PrixHisto
1             01/02/2012     28/02/2012       100.00
1             01/01/2012     31/01/2012       90.00
1             01/07/2011     31/12/2011       88.00
1             01/01/2011     30/06/2011       85.00

Quel est le prix du produit n°1 au 05/05/2011 ?

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
(
  SELECT PrixEncours AS Prix FROM Produit
  WHERE idProduit=1 AND DateMAJ<=#05/05/2011#
)
UNION ALL
(
  SELECT PrixHisto FROM HistoPrixProduit
  WHERE idProduit=1
       AND DateDebut<=#05/05/2011#
       AND DateFin>=#05/05/2011#
)

le prix actuel dans la table des produits et les anciens prix, avec la date, dans la table historique. C'est juste en quelque sorte un archivage des anciens prix.

c'est bien comme cela que je le vois également.

[Richard_35]

Bonjour à tous,

Je comprends l'argument, Fabien, néanmoins cela me gêne, malgré tout, de stocker une même notion de date/prix à deux endroits. C'est vrai que la requête UNION évite de "taper" à deux endroits différents.

Sinon, concrètement :

Produit(IdProduit, Libellé, ...) ;
HistoProduit(#IdProduit, DatePrix, Prix, ...).

Quel est le prix du produit n°[P] au 05/05/2011 ?

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT TOP 1 IdProduit, DatePrix, Prix
FROM HistoProduit
WHERE IdProduit=[P]) AND DatePrix<=#5/05/2011#
ORDER BY DatePrix DESC;

==> devrait le faire, non ?

[f-leb]

oui oui cela marche aussi.

Mais c'est un peu comme si tu rangeais au grenier un objet que tu utilises encore tous les jours, tu vois ?

[Richard_35]

Fabien,

Je vois, effectivement... jolie métaphore, mais les greniers virtuels sont bien plus facilement accessibles

D'ailleurs que sont les bases de données, dans le fond ?...