Discussion :

[dukoid]

Bonjour les amis,

je me demande avec quel modèle et comment gérer la mise à jour des produits pour un site d'e-commerce.
les commandes sont reliées à des produits.

par exemple, si on met un jour le prix d'un produit ou alors qu'on supprime un produit.
les anciennes commandes vont donc être affectées !

J'ai bien des idées mais je ne sais pas si c'est des bonnes pratiques alors je voudrais avoir l'avis de connaisseur...

[Sodium]

La réponse est dans la question, les clients doivent pouvoir avoir accès à leurs anciennes commandes, donc supprimer totalement les produits de la bdd n'est pas une bonne idée, il suffit de les flagger afin qu'ils n'apparaisse plus dans le shop, avec un champ "visibility" en bool par exemple.

[rawsrc]

ou utiliser la même approche que pour une facture : les tables factures et détails factures ne sont reliées à aucune autre table, tout est en dur (pour des questions d'inaltérabilité, aucun risque de faire un update dessus...).
Dès qu'un élément engageant les parties devient définitif, tu peux très bien l'isoler du reste des process de ton site.
Par ailleurs avec les nouvelles lois anti-fraude cette approche est fortement préconisée car elle permet de générer facilement des clés de signature (hash) tenant compte de la position d'un enregistrement par rapport aux autres (aucune rupture de continuité)

[dukoid]

@Sodium,
ok pour la suppression et dans le cas d'une mise à jour du prix ?

@rawsrc,
ok mais techniquement tu fais comment ? quoi comme modèle relationnelle ?

par exemple, je crée une table old_product et je relie la commande qui a été acté et signé avec cette table ?
c.a.d les produits de la commande signé, je les insères dans old_product et je les relies à cette commande. c'est une bonne pratique ?



ma question porte aussi pour une suppression d'un produit, qu'une mise à jour d'un prix entre les anciennes commandes et les nouvelles....

[Sodium]

Pour les mises à jour de prix le mieux serait probablement de stocker le prix payé par le consommateur dans des tables factures au moment de la commande, mais l'idéal serait probablement de garder une trace de toutes les modifications de prix de l'article dans le temps, ne serais-ce que pour des besoins statistiques.

[rawsrc]

tu dois raisonner en concept de stockage froid. C'est des tables (copies DDL des tables d'activité pour la plupart) qui figent tout à un moment donné. L'intérêt de ces tables c'est qu'elles sont déconnectées et ne possèdent aucun droit en modification et suppression.