Come progettare il diagramma ER per consentire il recupero dei dati sui prezzi delle opzioni di prodotto?

• Una categoria di prezzo è la combinazione di diverse opzioni e funzioni.
• Ma quelle opzioni e funzionalità devono essere applicabili / disponibili per quei prodotti
• Assemblate categorie di prezzo diverse tra quelle disponibili e le funzionalità per un determinato prodotto
• Hai una tabella della cronologia dei prezzi di ogni categoria di prezzo, quindi nessun prezzo è perso
• Non è necessario disporre di tabelle dei prezzi separate

Un PNG vale 1024 parole:

Lafunzionalitàel'opzionediassunzionedellaversionepiùsemplicesonolastessacosa,aggiungonodettaglisuiprezzi:

• Alcunerestrizioninonpossonoesseremodellateedevonoessereverificateconunaproceduradicontrollodiintegrità,comeadesempiochenonesisteunasovrapposizionedidateperlastessatabellastoricaihprezzo/prodotto/categoria.

Aggiornamento:

• PRICE_CATEGORYèunatabellaprincipaleeOPTION_CATEGORYèilsuodettaglio.Quindiunacategoriadiprezzoècomeuncombo/prodottocheaggiungemoltecosealprodottoprincipale.QuestecosesonoinOPTION_CATEGORY.
• L'FKdaOPTION_CATEGORYaAVAILABLE_PRODUCT_OPTèquellodiassicurarsichetounonpossaaggiungereopzioni/caratteristicheaunprodottochenonsiapplicaadesso,comeaggiungereunposacenereaunamoto.
• OPTION_CATEGORYhasoloFKsullealtreduetabelle

Unmodelloancorapiùsemplice:

• Prodotti e opzioni sono nella stessa tabella, dopo che tutte le opzioni sono anche prodotti.
• Una colonna indica se un prodotto è un prodotto di base o un'opzione.
• Essendo una singola tabella, è necessaria una singola tabella dei prezzi storica.
• La tabella OPTION è tra molti e molti tra i prodotti e indica loro quali opzioni sono teoricamente disponibili per ogni prodotto (niente vie di fuga per i motocicli)
• Un trigger su OPTION deve garantire che solo i prodotti di base abbiano opzioni.
• PRODUCT_COMBO è una combinazione denominata che consiste in un prodotto di base e una o più opzioni.
• Ovviamente solo le opzioni relative a un prodotto possono essere aggiunte a una combinazione.

Codifica sempre come se la persona che finisce per mantenere il tuo codice sia uno psicopatico violento che sa dove vivi

Creare 3 diverse tabelle di prezzo e aspettarsi che gli sviluppatori sappiano quale è rilevante tra 9 mesi richiede molto.

Personalmente, andrei con

price(id, price, start_date, stop_date)

e avere una tabella separata per le funzionalità:

productPrice(id, productId, priceId, option)

Usare solo un timestamp per il tuo prezzo ha il vantaggio di non doversi preoccupare di 2 record di prezzo con date sovrapposte. Tuttavia, ha lo svantaggio che ora i tuoi record di prezzo dipendono l'uno dall'altro: perdi un singolo record e sai che non conosci più il prezzo storico.

Che ne dici di questo:

price_lookupfungedafonteautorevoleperladefinizionedell'opzionecategoria-prodotto.

price_historydefinisceiprezziperlesuddetteopzionidiprodotto.

Oquesto:

price_history serve come record autorevole dell'opzione di prodotto e memorizza anche la cronologia dei prezzi per data. Il meglio di entrambi i mondi!

Per ottenere il prezzo corrente del prodotto:

select amount
from price_history 
where product_id = X and option_id = Y 
and date_from <= NOW() and NOW() <= date_to;