Progettazione della tabella SQL per prezzi che cambiano nel tempo

Question

Progettazione della tabella SQL per prezzi che cambiano nel tempo

#1 da (2 voti)

1

Sto sviluppando un database con una tabella di listino prezzi per il mio posto di lavoro. Sono arrivato con due opzioni principali e vorrei avere la tua opinione :)

È piuttosto semplice, contenente: Id , description e price

Da un lato, ora sta lavorando con ogni prezzo sulla nuova riga e con un campo extra start_date , ed è il modo in cui ho trovato sullo stack

Id  -  description    -  start_date  -  price
1   - some item       - 2018-10-30   -  500
2   - some other item - 2018-10-30   -  260
3   - some third item - 2018-10-30   -  921
4   - some item       - 2018-11-15   -  525
5   - some other item - 2018-11-15   -  310
6   - some third item - 2018-11-15   - 1025

Ma questo porta a molte descrizioni ripetute, calcolo non uniforme delle date durante la stampa degli elenchi dei prezzi.
Quindi sto pensando a questo altro approccio:

Id  -  description  -  2018-10-30  -  2018-11-15
1   - some item       - 500        -  525
2   - some other item - 260        -  310
3   - some third item - 921        - 1025

In questo modo l'ID e la descrizione sono unici e tutti i listini prezzi sono ordinati in modo splendido.
Per aggiungere un nuovo listino prezzi (nel mio caso, la maggior parte delle modifiche saranno aggiornamenti di questo elenco) fai semplicemente su ALTER TABLE prices ADD now() INT; seguito dal UPDATE di

In la tabella dei prezzi di progettazione (agnostico RDBMS) sembra che tutti stiano attaccando alla prima opzione, ma

Quindi, alle domande ...
Avrò mal di testa nel secondo?
Mi manca qualcosa?
Dovrei attenermi alla prima opzione per qualche motivo?

sql database-design

posta GasparAlbert 30.11.2018 - 21:21

fonte

1 risposta

Leggi altre domande sui tag sql database-design

Usando UNIQUE (col1, col2) o usando una chiave primaria composta per una tabella delle relazioni in SQLite / SQL? Comunicazione in un'architettura microservizi con pallone e REST

score 2 · Accepted Answer

Sembra che tu abbia una relazione uno a molti tra prodotti e prezzi. L'approccio standard consisterebbe in due tabelle. Una tabella può essere prodotti con la descrizione dell'ID e qualsiasi altra cosa correlata al prodotto, mentre l'altra sarebbe costituita da prezzi con una chiave esterna per prodotti, data di inizio e prezzo. Ciò risolve la duplicazione e non è davvero difficile ottenere il prezzo corrente di qualsiasi cosa e consente facilmente di mostrare la cronologia dei prezzi di un prodotto.

Un'altra opzione un po 'macchinosa è avere una tabella come l'opzione uno e una tabella della cronologia dei prezzi. quando è necessario aggiungere una nuova data, inserire la data / prezzo esistente nella tabella della cronologia e aggiornare la riga originale. Ciò rende semplice ottenere il prezzo attivo, ma non funziona bene con l'impostazione dei prezzi futuri e fa affidamento su trigger o procedure per garantire l'integrità dei dati.

La tua seconda opzione è una scelta sbagliata perché ogni volta che aggiungi un nuovo prezzo devi aggiornare il codice per utilizzare la nuova colonna o eseguire alcuni calcoli sulle colonne per determinare quello corretto. Inoltre, aggiungendo più colonne si arriva a un punto in cui la tabella è lenta per eseguire query in modo abbastanza rapido, la maggior parte dei database viene ottimizzata in base all'espansione delle righe, molte colonne possono davvero rallentare una query.