Come conservare la cronologia dei prodotti e dei prezzi in un database di prodotti?

-1

Qual è il modo migliore per archiviare informazioni storiche su prodotti e prezzi in un database?

I nostri fornitori ci forniscono cataloghi in vari formati che normalmente contengono

  • ID del produttore del prodotto,
  • nome del prodotto,
  • GTIN-13,
  • e MSRP.

Sulla base di queste informazioni mi piacerebbe creare un database di prodotti con

  • il mio ID per il prodotto,
  • il mio nome per il prodotto,
  • produttore del prodotto,
  • fornitore del prodotto,
  • ID del produttore del prodotto,
  • nome del produttore per il prodotto,
  • GTIN-13,
  • MSRP,
  • costo di acquisizione,
  • prezzo alla rinfusa per i miei clienti,
  • e ovviamente prezzo di vendita per i miei clienti.

Poiché acquistiamo direttamente dai produttori o dai loro distributori esclusivi, e ogni prodotto ha un unico fornitore, questa sarebbe una semplice tabella db. Tranne, vorrei anche memorizzare informazioni storiche su prezzi e prodotti .

Innanzitutto, ovviamente il prezzo cambia. Mi piacerebbe conservare informazioni sul prezzo corrente mentre imposto il nuovo. Ogni prezzo (MSRP, acquisizione, merce sfusa, vendita al dettaglio) può cambiare in modo indipendente, con la vendita al dettaglio che viene persino regolata manualmente per adattarsi alle condizioni del mercato.

In secondo luogo, modifiche minori del prodotto. Abbastanza regolarmente, i produttori rilasceranno nuove versioni di vecchi prodotti con leggere modifiche all'ID del produttore, al nome del prodotto e al GTIN-13. Purtroppo, vecchie e nuove versioni possono coesistere per un po ', contraddistinte dall'ID del produttore. Desidero conservare le informazioni sulle modifiche ai prodotti (ID del produttore precedente, nome, GTIN-13, MSRP, costo di acquisizione) con lo stesso my_ID .

Infine, importanti cambiamenti di prodotto. Occasionalmente, i produttori rilasceranno completamente nuovi prodotti sostituendo alcuni di quelli vecchi. E non necessariamente 1: 1, anche coesistendo a lungo. È possibile impostare un singolo nuovo prodotto per sostituire più prodotti attualmente trasportati e più nuovi prodotti possono sostituire un singolo prodotto attualmente trasportato. Mi piacerebbe avere una sorta di albero genealogico di questo.

Quale sarebbe una scelta intelligente di struttura dei dati (base) qui? Idealmente qualcosa che può essere supportato da PostgreSQL.

Stavo pensando di avere quella singola tabella per le informazioni correnti e un'altra per l'event sourcing per mantenere le modifiche. Con quello in atto, vorrei semplicemente scambiare nuove informazioni dal fornitore con lo stesso my_ID . È appropriato o lo considererò un doloroso errore in futuro? Cosa devo fare per le principali modifiche al prodotto?

    
posta Damn Terminal 25.06.2017 - 15:20
fonte

2 risposte

2

Preferirei lasciare la tabella corrente così com'è e aggiungere una tabella per contenere le cronologie dei prezzi, che sono correlate tramite l'id del prodotto e con un timestamp, e un lavoro giornaliero per l'istantanea dei prezzi di oggi nella cronologia.

Potresti voler riflettere ulteriormente su quali problemi di business potrebbero derivare dal fatto che il luccio abbia a che fare con la cronologia dei prezzi. Un esempio che viene in mente è il monitoraggio della validità o meno di una promozione, e quindi il motivo del prezzo.

Probabilmente sarà anche necessario monitorare le quantità di vendita al giorno, in modo da poter mostrare le tendenze settimanali, mensili, trimestrali e annuali sulle vendite.

Andare oltre un singolo tavolo non è affatto male. Maggiore è la business intelligence che la tua applicazione può fornire, meglio è.

    
risposta data 25.06.2017 - 17:18
fonte
2

Mantieni la stessa struttura, ad eccezione dell'estrazione dei dati di prezzo in una tabella separata. Questa tabella condividerebbe la chiave primaria della tabella degli articoli, tranne che aggiungerebbe un campo DATETIME per la data effettiva. Ottieni una cronologia completa dei vecchi prezzi e quando sono diventati effettivi e puoi facilmente richiedere il prezzo corrente trovando il record corrispondente a un determinato articolo con la data di efficacia più recente.

So che funziona perché ho lavorato con sistemi simili diverse volte e tutti hanno usato questo stesso modello. Ha funzionato molto bene.

    
risposta data 25.06.2017 - 17:51
fonte

Leggi altre domande sui tag