Progettazione del database: domanda sull'efficienza (e sulla qualità generale della progettazione)

Question

Temo di non sapere cosa sto facendo.

1:

Ho un tavolo chiamato ticket che ha una colonna chiamata total.Quando il totale viene aggiornato, voglio tenerne traccia (vecchio totale, ecc.), quindi ho deciso di rimuovere il file total colonna e creare una tabella chiamata ticket_total con colonne ticket_id, total, E datetime (il più recente ovviamente è il totale “attuale”).

O

2:

Poi ho capito che in seguito avrei voluto dare ai miei clienti la possibilità di ordinare i biglietti in base a total, o estrarre report che aggregano i totali, ecc.Quindi, ho deciso invece di rimettere a posto il total colonna attiva ticket, e per modificare il total colonna direttamente quando il totale viene aggiornato, ma prima crea una colonna ticket_total riga come record della precedente total.

Sembra che la versione 2 sarebbe altamente efficiente perché non avrei bisogno di interrogare il file correlato ticket_total table, ma mi chiedo cosa ne pensiate voi guru del DB là fuori.Sto solo imparando la progettazione di database e temo che non sarò mai bravo.

Answer 1

Vorrei andare con l'opzione 2 che avete suggerito.

Basta fare in modo che si sta facendo l'aggiornamento (del biglietto) + Ins (in ticket_total) in una transazione per assicurare che l'integrità è mantenuta.

Answer 2

La seconda alternativa è più veloce, ma se si desidera creare report sui valori storici del totale, si dovrebbe dovrebbe avere una tabella separata in cui si memorizza il valore che si sta sostituendo con un timestamp. Questo tipo di tabella è indicato come un tabella di controllo .

Answer 3

Rif:"efficienza" -- la cosa migliore è non preoccuparsi troppo dell'efficienza del database all'inizio di un progetto.L’ottimizzazione prematura è un errore comune da evitare.

È meglio concentrarsi sulle proprie esigenze e progettare in base a esse.Successivamente, puoi testare per vedere dove sono i colli di bottiglia nelle prestazioni e lavorare per risolverli.

Per i database più piccoli (decine di migliaia di righe), anche le query "inefficienti" spesso vanno molto velocemente, dati i server e il software di oggi.

Mantienilo semplice Ti suggerisco di evitare combinazioni di tasti e sovraccaricare la semantica della tabella a meno che tu non ne abbia realmente bisogno.

Proposta Hai due tipi di dati:informazioni sul biglietto attuale e una tabella della cronologia per i vecchi valori "totali".

Quindi la tua versione 2 sarebbe preferibile.

ticket
  id
  field_a
  field_b
  total    # current_total

ticket_total  # history of ticket total field
  id
  ticket_id
  total
  create_time

Anche "totale" suona come un'aggregazione di qualcosa.Ti suggerisco di provare a trovare un nome di campo più descrittivo.-- Qual è il campo in totale?"totale_orario di lavoro"?

Aggiunto Ricordarsi di aggiungere gli indici per le tabelle.Indicizza in base a tutto ciò che usi per le ricerche.Ad esempio, la tabella dei ticket ha un customer_id?Assicurati che sia indicizzato.

Answer 4

Vorrei fare ticket_total vista, non un tavolo. Vorrei creare un altro ticket_current vista dove avrei filtrare i biglietti per l'ultima data, che è se la tabella biglietto è duale a chiave su ticket_id e datetime. In caso contrario, disprezzo che l'ultima parte.