Come posso identificare quando creare una nuova tabella per contenere i dati che possono essere ottenuti da una query?

Abbiamo una tabella dei pagamenti e gli agenti ricevono una commissione sui pagamenti. La commissione si basa su alcuni fattori diversi, come il tempo impiegato per ottenere il pagamento, quindi ci sono alcuni calcoli coinvolti nel determinare il tasso di commissione che ottiene l'agente, ma nulla di oscenamente complesso.

Ad esempio, probabilmente non sarà mai più complesso di così:

SELECT Payments.Amount * CASE 
    WHEN DateDiff(year, Client.Received, Payments.DatePaid) = 1 THEN Rates.Rate1
    WHEN DateDiff(year, Client.Received, Payments.DatePaid) = 2 THEN Rates.Rate2
    ELSE Rates.Rate3 END

Avrebbe senso costruire una seconda tabella per contenere questi dati invece di interrogarli ogni volta che è necessario? O dovrei semplicemente attenermi alle query di runtime che estraggono i dati ogni volta che vengono richiesti?

E, soprattutto, quali sono i fattori da utilizzare per determinare se una query deve essere eseguita ogni volta che sono necessari i dati o se i dati devono essere archiviati in una tabella separata?

sql-server sql-server-2005 query-performance

— Rachel
fonte

Una domanda chiave è "con quale frequenza le persone desiderano interrogare questi dati?" È un rapporto o uno schermo pesantemente trafficato nell'applicazione?

— Preoccupato di

@ConcernedOfTunbridgeWells In questo caso, è un rapporto che viene eseguito alcune volte al mese, forse più spesso se lasciamo che gli agenti eseguano il rapporto da soli per visualizzare la loro commissione.

— Rachel,

Probabilmente è meglio inserirla in una tabella di report su un processo durante la notte e la commissione è "come ieri sera". Se hai una procedura di chiusura in cui devi chiudere, segnala quindi potresti fornire una struttura nell'app per forzare una ricostruzione.

— Preoccupato di

Le date "AsOf" sono abbastanza comuni con questo tipo di operazioni in un contesto finanziario, secondo la mia esperienza. Pertanto, una tabella (come nota @ConcernedOfTunbridgeWells) con tale data "AsOf" dovrebbe essere perfettamente accettabile.

— swasheck

Articolo correlato: dba.stackexchange.com/q/7592/2660

— Nick Chammas,

Risposte:

Se la query viene eseguita abbastanza raramente (ad esempio un report), probabilmente è meglio costruire la tabella al volo ¹ . Se la query viene eseguita frequentemente e la tabella temporanea è richiesta per le prestazioni, è possibile che si sia verificato un problema.

Se la tabella è economica da costruire, allora fallo come tabella temporanea. Finché il database è abbastanza veloce, potresti cavartela. Tuttavia, dovrai tenere d'occhio le prestazioni.
Se la tabella non deve essere completamente aggiornata, ma sarà oggetto di attività di reporting relativamente frequenti rispetto a una ricostruzione periodica, è probabilmente il modo migliore di procedere.
Se la tabella è costosa da costruire ma deve essere aggiornata, potrebbe essere necessario gestirla come una struttura denormalizzata, mantenuta come una vista indicizzata o tramite trigger. Questo è piuttosto più complicato e comporta un ulteriore onere per le operazioni di scrittura.

In casi più estremi (ad es. Grandi volumi di dati) potrebbe essere necessario un approccio ibrido in cui i dati storici vengono interrogati da una struttura denormalizzata ottimizzata per le prestazioni e i dati correnti vengono interrogati dall'applicazione live.

I casi più estremi di questo possono portarti a feed di dati mart a bassa latenza e soluzioni OLAP ibride, quindi questo è di gran lunga il più complesso in termini di profondità della tana del coniglio. È meglio evitarlo a meno che tu non abbia un vero requisito.

Nel caso descritto sopra, una ricostruzione periodica di una tabella di report sembra appropriata. Se è necessario chiudere a metà giornata per eseguire i report, è possibile fornire una funzione per forzare un aggiornamento dall'applicazione. Altrimenti eseguirlo su un processo durante la notte e gli agenti possono vedere la loro commissione "come a mezzanotte del giorno lavorativo precedente".

¹ select into query che creano tabelle temporanee sono abbastanza veloci su SQL Server perché le operazioni di inserimento sono minimamente registrate.

Quindi per riassumere, usi i seguenti fattori per determinare se dovresti avere una nuova tabella per i tuoi dati o meno:

Con quale frequenza sono necessari i dati
Quanto costa ottenere i dati
Quanto devono essere aggiornati i dati

— ConcernedOfTunbridgeWells
fonte

Quindi fondamentalmente gli unici due fattori che usi per determinare se hai bisogno di una tabella permanente per i dati invece di interrogarli quando necessario sono how often the data is needede how expensive the query is?

— Rachel,

@ Rachel - Inoltre, "quanto devono essere aggiornati i dati?"

— ConcernedOfTunbridgeWells

Un problema non trattato nella risposta accettata è "hai bisogno di questo valore nel tempo" e "la formula potrebbe cambiare"?

Ad esempio, prendere in considerazione l'esempio della commissione. Se la commissione viene pagata, l'importo deve essere archiviato in quanto è una cifra storica di ciò che è stato effettivamente pagato. Il modo di calcolare le commissioni potrebbe cambiare il mese prossimo (e lo fa spesso) ma ciò non cambierà ciò che è stato effettivamente pagato che deve essere memorizzato separatamente.

È la stessa idea di memorizzare il prezzo che il cliente ha effettivamente pagato per un prodotto (dopo un calcolo di sconti, ecc.) Piuttosto che fare affidamento su una formula rispetto a una tabella dei prezzi per fare qualsiasi cosa tranne il calcolo iniziale perché il prezzo del prodotto il mese prossimo potrebbe non essere lo stesso di quello che era il prezzo quando il cliente ha fatto l'ordine.

Se hai bisogno di un record storico di quale fosse il valore in un determinato momento, memorizza sempre quel valore dopo aver usato la formula per la calibrazione iniziale.

— HLGEM
fonte

Grazie, è sicuramente qualcosa da considerare quando si prende questo tipo di decisione. Questa volta, il valore non cambierà perché la commissione viene impostata una volta per agente e per cliente quando il cliente viene ottenuto e la tariffa utilizzata si basa sulla data del pagamento e sulla data in cui abbiamo ricevuto il cliente, nessuna delle quali sono valori che cambiano.

— Rachel,

@Rachel: nessuno dei due sono valori che al momento prevedi di cambiare. Naturalmente, se lo fanno il cambiamento è sempre possibile creare una tabella di dati storici in quel momento, se ne avete bisogno, a patto che non si dimentica sulla questione.

— ps

Probabilmente non è interessante se sei bloccato in un particolare database, ma MariaDB (simile al lavoro basato su MySQL) ha qualcosa di meraviglioso chiamato "colonne virtuali" che può essere calcolato al volo o memorizzato nella cache nella memoria effettiva, ma automagicamente ricalcolato secondo necessità. Ho perso questa funzionalità da quando ho lasciato FileMaker Pro per il mondo SQL molti anni fa ...

— Jan Steinman
fonte