Il miglior approccio per un negozio online che modifica il prezzo del suo prodotto nel tempo? [Progettare la tabella DB]

2

Attualmente sto creando un sito web che permetterà alle persone di acquistare prodotti di consumo (deodoranti, shampoo, dentifrici, ecc.) da un negozio. Questi prodotti tendono a cambiare prezzo e altri dettagli due volte all'anno o più. E voglio mostrare i prezzi degli acquisti passati e altri dettagli al cliente. E volevo sapere qual è l'approccio migliore. Sono arrivato con i seguenti approcci. Sono buoni?

Grazie!

1 °. Approccio: ho una tabella di prodotto, con le colonne che tendono a cambiare, aggiunte al momento del cambiamento come suffisso.


2°approccio:inquesto,hoilprezzoealtridettagliinunacolonnaseparata. 


Ho fatto qualche ricerca: Come conservare i prezzi con date efficaci? link

Ma non sono riuscito a trovarli appropriati per il mio problema.

    
posta Jose A 06.10.2014 - 22:12
fonte

3 risposte

8

Invece di creare una tabella separata per ogni data, crea una singola tabella dei dettagli e indice per id prodotto e data effettiva:

ProductDetails:
   productId 
   dateEffective 
   price
   ...

In questo modo, inserisci una nuova riga ogni volta che i dettagli cambiano.

insert into ProductDetails( productId, dateEffective, price )
values ( 1234567, '10/06/2014', 1.25 );

Quindi ottieni il prezzo in base all'id del prodotto e alla data; in questo modo, puoi ottenere il prezzo corrente per i nuovi ordini e ottenere il prezzo per gli ordini passati in base alla data.

select price, dateEffective from ProductDetails where productId = 1234567 and
dateEffective between date1 and date2;

Non vuoi davvero creare un gruppo di tabelle separate per periodi di tempo diversi, e davvero non vuoi continuare ad aggiungere colonne alla tabella Prodotto ogni volta che aggiorni i dettagli.

    
risposta data 06.10.2014 - 22:30
fonte
3

Se hai una cosa, che ha alcuni attributi che non possono cambiare e altri che possono cambiare nel tempo, hai davvero due cose separate. Questo significa che dovresti considerare di dare a ciascuna "cosa" il proprio tavolo.

Nessuna delle tue opzioni usa il modello di database per rendere più facile il lavoro a nessuno. La selezione di tabelle completamente diverse è una pratica fastidiosa, ma occasionalmente necessaria come preoccupazione di implementazione per insiemi di dati molto grandi. Selezionare colonne diverse è un'idea TERRIBILE, che urla per ulteriore normalizzazione.

Utilizza una tabella separata per i prezzi, con intervalli di date o un modello "attuale o più vicino nel passato". Qualsiasi altra cosa è un mal di testa che dovresti evitare a meno che tu non abbia una buona ragione per non farlo.

    
risposta data 06.10.2014 - 22:42
fonte
1

Un design pulito è se hai una data di inizio e una data di fine per ogni prezzo:

per un nuovo prodotto:

  • inserire nel prezzo set product = X, startDate = now (), endDate = infinity

per una variazione di prezzo:

  • inserire nel prezzo set product = X, startDate = now (), endDate = infinity
  • inserire gli inneschi del trigger: prezzo aggiornato set endDate = now () dove product = X e endDate = infinity

In questo modo puoi anche modellare facilmente i periodi quando non c'è prezzo.

Avanzato: può essere usato anche per la registrazione dei prezzi, quindi il prezzo corrente reale è in una tabella e basta aggiornarlo e la tabella di registrazione viene automaticamente riempita da un trigger con startDate e endDate come descritto sopra.

    
risposta data 07.10.2014 - 03:42
fonte

Leggi altre domande sui tag