Dove si dovrebbero mettere gli indici in una tabella dimensionale?

Dopo aver letto le Domande e risposte di questo sito Web sugli indici, mi è venuta in mente una domanda.

Che cosa succede se si utilizza una tabella delle dimensioni temporali con il livello di granularità inferiore al giorno. Dove si dovrebbero mettere gli indici?

Randy Melder nella domanda: cosa significa "indice" su RDBMS? disse :

Pensa a un indice come a "indice" ... che è un elenco ordinato di puntatori a posizioni in un file, noto anche come offset

Nel caso della dimensione temporale, la maggior parte delle ricerche sui dati potrebbe essere effettuata per un giorno specifico, una settimana specifica, un mese specifico o un trimestre specifico se la tabella dei tempi memorizza tutto il giorno per un anno unico .

La mia domanda è: si dovrebbero mettere gli indici per tutti quei campi?

Il giorno dovrebbe essere unico, quindi per questo capisco perfettamente l'uso degli indici. Ma un id settimana avrà 7 ricorrenze , un id mese avrà 30/31 occorrenze , un id quarto avrà più o meno 120 occorrenze .

• Si dovrebbero ancora mettere gli indici per quei campi?
• Sarà ancora utile?

Te lo sto chiedendo perché nella stessa domanda, David Spillett ha detto:

L'aggiunta di troppi indici può ovviamente essere una cattiva ottimizzazione, poiché lo spazio aggiuntivo utilizzato per memorizzare gli indici (e il carico di I / O per mantenerli se il DB vede molte operazioni di scrittura) potrebbe essere un problema peggiore rispetto alle query di lettura leggermente meno ottimali , quindi non esagerare.

Quindi quali sarebbero le migliori considerazioni per il caso della dimensione temporale?

Probabilmente non ti imbatterai in problemi di scrittura, poiché presumo che questo sarebbe qualcosa di creato una volta (o una volta all'anno) e quindi non toccato.

Ma l'utilizzo di un indice sarà probabilmente un ostacolo se stai effettuando una ricerca per settimana ... Il problema è che, se viene utilizzato l'indice, potrebbe prima scansionarlo, quindi prendere ogni record dalla tabella individualmente, che quando rielaborando più del 5-20% circa dei record, in genere è più veloce eseguire una scansione completa della tabella, quindi rilasciare i record che non ti interessano.

Non conosco i principali RDBMS che non ottimizzano per questo quando si tratta di dati ben distribuiti. Se non è ben distribuito (ad esempio, uno dei valori in una colonna si verifica il 95% delle volte, ma ci sono anche altri valori possibili), potrebbe essere necessario calcolare gli istogrammi sulla tabella e non utilizzare un segnaposto per il valore durante la ricerca, in modo che Query Optimizer abbia il valore cercato durante la generazione del piano di esecuzione.

Probabilmente non indicizzerei il giorno della settimana. Verificherei la documentazione del mio database per vedere quale sia il loro compromesso per letture indicizzate rispetto a scansioni di tabelle complete per vedere se indicizzerei il giorno del mese o il mese dell'anno. Probabilmente indicizzerei DOY / giorno dell'anno se presente (il che sembra comunque il tuo indice univoco)

Un indice non deve essere unico per essere utile, quindi la risposta è che dipende . Se le tue query beneficiano della presenza dell'indice, potrebbero essere utili. Non so che dovrebbero esserci delle linee guida speciali per quanto riguarda le colonne temporali. Trattali come qualsiasi altra colonna e indicizzali in base all'utilità delle query.

La regola generale è che più selettivo è l'indice (la selettività viene definita come il numero di valori univoci in una colonna diviso per il numero di righe nella tabella), più è probabile che il motore utilizzi l'indice se una query utilizza la colonna in una clausola where.

Se stai pensando di indicizzare una colonna, eseguire una query selezionando prima e dopo sulla colonna indicizzata e guardando i piani di esecuzione ti dirà se l'indice viene utilizzato e, in tal caso, quanto l'indice sta aiutando. Idealmente, la query utilizzata per il test è quella che verrebbe utilizzata dall'applicazione.

Finora, la mia regola empirica è stata quella di non inserire alcun indice nei miei database di sviluppo mentre ci sto lavorando. Man mano che il database di produzione diventa più grande, utilizzo la registrazione del database e EXPLAINper capire cosa necessita di indicizzazione, quindi creo solo gli indici necessari. Funziona bene finché l'utilizzo del database aumenta gradualmente e mantiene bassi i conteggi degli indici.

Quando analizzo i dati nel database, di solito ho bisogno di aggiungere altri indici per accelerare le richieste che non sono comuni nella produzione. Lo faccio sempre su copie del database di produzione, quindi questi indici non vengono mai aggiunti alla produzione stessa.