Discussion :

[beaudelaire]

Bonjour:
j'ai une BD qui gère les ventes d'un établissement commercial. La table ARTICLES(id_article, désignation, PrixUnitaire). Ce que j'aimerai savoir est comment mettre à jour par exemple le PrixUnitaire d'un article si le prix de ce dernier venait à changer, sans pour autant mettre à jour les précédents enregistrements qui ont été fait avec un prix différent.
Merci d'avance!

[Reward]

Salut,

Tu dois sélectionner l'enregistrement à mettre à jour en fonction de ton article grâce à son id.

Exemple: Tu dois changer le prix d'un article dont la désignation est "paire de baskets". Tu récupère son id (id_article). Tu fais ensuite une requête pour la mise à jour du genre :

Code :

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

1
2
UPDATE ARTICLES, SET PrixUnitaire = 100 
WHERE article_id = 1;

[beaudelaire]

Le problème est que j'établis les factures par la même occasion. Imaginons que je veuille retrouver la commande passé par un client à une certaine date antérieure à celle où j'ai modifié le prix de l'article. Je voudrais savoir si la mise à jour du prix de l'article affectera sur les commandes effectuées avec l'ancien prix

[Invité]

Dans le cas présent, oui, par rapport à ton besoin tu dois créer une table de prix pour chaque article avec la période pendant laquelle le prix était valable.

De cette tu peux utiliser ton article comme tu veux, et quand tu édites une facture tu récupères le prix valide lors de l’établissement de la facture.

[Reward]

Comme le dit gcorbineau, une évolution de ton modèle de données sera nécessaire pour prendre en compte ton besoin.

[Kropernic]

Le plus simple est je pense d'ajouter une colonne de type Datetime dans ta table ARTICLES qui prendra GetDate() en valeur par défaut. De cette manière tu pourras savoir à quel moment ce prix est entré en application et tu pourras faire les requêtes adéquates.

[VITALTH]

En revanche tu ne mettras pas à jour (pas de "UPDATE") lors du changement de prix : tu ajouteras un enregistrement.

Imaginons que ta table à comme clé primaire "id_article" + "DateModif" :
Ta requête devient :

Code sql :

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

INSERT INTO articles (id_article, designation, prixunitaire) VALUES (1,'Basket',100);

A priori tu n'a pas à mettre à jour la date de Modif (nvx champs DateModif) puisque si tu utilises la proposition de Kropernic, elle a pour valeur par défaut GetDate().

Tu peux également créer un champs clé primaire dans ta table de type AutoIncrement (selon le type de ta BD) et enlever la clé sur id_article, la requête resterait à prioris la même.

Quand tu voudras sélectionner le prix d'un article à une date précise tu auras :

Code sql :

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

SELECT prixunitaire FROM articles WHERE id_article = TonArticle AND datemodif = TaDate

[peregna2007]

Bonjour à tous,

Je pense que devrais avoir une table VENTES où tu retraces toutes les ventes. Ainsi ta table article reste intacte. Même si tu changes le prix unitaire, les anciens prix de la table VENTES resteront inchangés. Les nouvelles ventes prendront les nouveaux prix.

[Bluedeep]

Bonjour à tous,

Je pense que devrais avoir une table VENTES où tu retraces toutes les ventes. Ainsi ta table article reste intacte. Même si tu changes le prix unitaire, les anciens prix de la table VENTES resteront inchangés. Les nouvelles ventes prendront les nouveaux prix.

Oui, la logique veux de toute manière d'avoir une table d'historique pour les lignes et les en-têtes de facture (si on change l'adresse d'un client, on doit pourtant pouvoir sortir un double d'une facture avant le changement d'adresse où apparait l'ancienne).