Historique des prix pour les factures?

Question

Lorsque le client passe une commande, les éléments item_id et option_id sont stockés dans la table order_items, à partir de laquelle il génère une facture pour le client. Cependant, le prix de l'article change toujours tous les quelques mois et cela affectera les anciennes informations sur les factures.

Quelle est la solution pour résoudre ce problème? Je ne veux pas stocker le prix et le nom de l'article dans la table order_items. J'ai lu la solution possible est de créer une table history_prices (système d'audit via trigger ou requête d'insertion SQL manuellement via php?), Est la meilleure solution d'audit ou existe-t-il une autre solution?

Pouvez-vous fournir un exemple comment créer une table history_prices, alors quand je change le prix de item_options.option_price - il sera stocké dans la table history_prices?

À l'heure actuelle, j'ai plus de 200 000 lignes dans la table item_options, dois-je copier les prix dans history_prices?

J'ai besoin d'un moyen efficace afin que les factures ne seront pas affectées par le nouveau changement de prix.

table item_options:

mysql> desc item_options; 
+---------------+--------------+------+-----+---------+----------------+ 
| Field   | Type   | Null | Key | Default | Extra   | 
+---------------+--------------+------+-----+---------+----------------+ 
| option_id  | int(11)  | NO | PRI | NULL | auto_increment | 
| item_id  | int(11)  | YES | MUL | NULL |    | 
| option_name | varchar(100) | YES |  | NULL |    | 
| option_price | int(11)  | YES |  | NULL |    | 
+---------------+--------------+------+-----+---------+----------------+ 

table ordre_items:

mysql> desc order_items; 
+----------------+---------+------+-----+---------+----------------+ 
| Field   | Type | Null | Key | Default | Extra   | 
+----------------+---------+------+-----+---------+----------------+ 
| order_items_id | int(11) | NO | PRI | NULL | auto_increment | 
| order_id  | int(11) | NO |  | NULL |    | 
| item_id  | int(11) | NO |  | NULL |    | 
| option_id  | int(11) | NO |  | NULL |    | 
+----------------+---------+------+-----+---------+----------------+ 

Answer 1

Vérifiez les points suivants sur les designs:

Design 1: Enregistre une histoire de roulement des modifications apportées à l'élément (nouvelle ligne si tout change: nom, description, prix).

Modèle 2: Nouvelle rangée sur Changement de prix seulement.

Vous pouvez également enregistrer le prix avec la commande elle-même.

Answer 2

Ceci est une question d'opinion, certains seront d'accord qu'un prix historique recherche sera ok, mon avis est que ce n'est pas . Le problème avec la recherche d'un historique des prix et la détermination du prix de la facture est qu'il y a beaucoup de place pour l'erreur. Vous aurez plusieurs éléments de logique utilisés pour déterminer le bon prix, qui sont tous sujets aux erreurs. Vous pourriez oublier de convertir le fuseau horaire de la facture, ce qui pourrait l'amener à être du mauvais côté d'un changement de prix. Vous pourriez oublier de faire des remises appliquées ou des codes de coupon sensibles à la date, etc. Qu'en est-il de changer les frais d'expédition?

Il est préférable de stocker le prix facturé réel avec la facture elle-même. L'espace disque est bon marché, utilisez la redondance pour mieux dormir la nuit.

Answer 3

La meilleure chose que vous pouvez faire est de créer une colonne en order_items pour le prix. Et c'est aussi le plus simple.

Si vous souhaitez créer une table avec l'historique des prix pour l'utilisation de rapports, cela pourrait être bon. Mais ne vous donnez pas le mal de tête douloureux d'interroger l'historique des prix juste pour obtenir le prix de certains articles. Le prix est un attribut de l'article. Le prix pourrait changer en raison de la promotion, réduction, offre spéciale, etc.