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.

[dukoid]

merci pour vos réponses.

@rawsrc,

à chaque modification de prix :
(1) il faut créer une copie de la table ? (ça risque pas d'avoir X tables...)
(2) modifier le prix de la table en cours

après, comment doctrine va savoir ou allez voir dans quelle table ?

je ne trouve pas grand chose comme info à ce sujet sur le net..

[rawsrc]

non, à chaque fois qu'un document est définitivement validé, tu le stockes dans la table très longue durée et cet enregistrement fait foi. Les autres tables (prix, catalogues...) continuent leur vie. Tu peux y faire autant de modifs que tu veux, le plus important c'est que les informations relatives aux engagements fermes ne soient plus modifiables.

Après pour ce qui est de doctrine, je ne pourrais pas t'aider, je dois t'avouer que les ORM me filent des boutons. J'utilise une autre approche : je pose la structure de mes ressources SQL (aussi complexes soient-elles) et j'ai un système qui me remplit uniquement les parties dynamiques selon les règles que je définis.

[Sodium]

Pour chaque modification de prix, tu crées une entrée dans une table de mises à jour de prix. Doctrine traite ça comme n'importe quel entité, c'est une table avec le nom du produit, code barre, date, prix, etc.

[dukoid]

ok merci pour vos réponses

@sodium,
peux tu me décrire les étapes, j'ai du mal à voir le principe.

disons qu'on a des commandes passées
une table produits
et de futur commandes donc...


je modifie le prix d'un produit, et donc ? techniquement il faut faire quoi ?

[Sodium]

Je ne vois pas ce qui te pose tant problème en fait. Tu crées une nouvelle table avec toutes les informations dont tu as besoin (nom du produit, code barre, nouveau prix, date...) et tu fais une insertion dedans chaque fois que tu fais une mise à jour de prix, ce n'est pas compliqué que ça.

[dukoid]

@sodium,


j'ai une table produit.

je fais une modif de prix donc dans la nouvelle table produit2, j'enregistre le produit avec le nouveau prix et donc les futurs commandes auront un lien avec les produits non modifé de la table produit et un lien vers produit2 si c'est un produit avec un code modifié donc -< j'imagine déjà la confusion que ça peut avoir

ensuite si encore plus tard, je dois modifier encore modifier le prix je dois refaire une table produit3 ?? ...... je vais jamais m'en sortir....


moi je trouve que c'est pas compliqué d'expliquer avec des cas concrets qu plutot être vague, sans exemple...
(ou alors c'est moi qui est débile... tout est possible )

[Sodium]

Mais pourquoi veux-tu faire plusieurs table o____o
Tu fais UNE table de changements de prix, quand un produit change de prix tu rajoutes un ligne dedans.
Encore une fois je veux bien t'aider mais je ne comprends pas ce que tu ne comprends pas.
La nouvelle table n'est pas une copie de la table produits, c'est juste un log, un historique des changements de prix de tous les articles.

[dukoid]

non désolé je ne comprends pas... laisse tomber !