La creazione della parte indice del database del processo di progettazione, implementazione o ottimizzazione?

Per ragioni di discussione, specifichiamo in cosa intendiamo (e presumiamo che tu stia facendo TDD):

• Design è il processo per specificare la forma totale del tuo sistema. È possibile (e talvolta dovrebbe) progettare senza scrivere direttamente o indirettamente una singola riga di database o codice di programma. Definisci i tuoi test di accettazione come ultima fase di progettazione.
• Implementazione è il processo per trasformare detto progetto in un software "funzionante". Se sei dogmatico, non scriverei un solo indice di database; dovresti semplicemente definire le tabelle, scrivere l'oggetto dell'interfaccia e affidarti alla tua piattaforma di livello inferiore per caricare i dati. Scrivi Test unitari e Test di integrazione durante l'implementazione, e l'implementazione viene eseguita quando tutti i test di accettazione passano.
• Ottimizzazione sta rendendo il software "funzionante" che hai implementato nell'implementazione e accelerandolo laddove viene eseguito in modo inaccettabilmente lento. I tre livelli di test ti consentono di apportare modifiche senza rompere nulla.

Naturalmente, è così che funziona in teoria. Ma dal punto di vista pratico, dal momento che il tempo e il denaro sono entrambi limitati, farai spesso i passi fuori ordine. Se ti aspetti di aver bisogno di un indice su un particolare campo, non c'è ragione di non indicizzarlo mentre lo progetta. Se mentre sei in preda alla codifica ti rendi conto di come puoi risolvere elegantemente una situazione d'uso alternativa, puoi andare avanti e codificare una bozza prima e scrivere il test unitario secondo. (E quando ti rendi conto che il tuo design è sbagliato, dovrai tornare indietro e rivedere i tuoi test comunque.)

Per le tue domande particolari:

Is creating all indexes at the start (design) over engineering?

No, se tutti sono indici utili e non impiegano molto tempo.

Sì, se si finisce per definire gli indici per le tabelle che sono lontane persino dal primo prototipo approssimativo. (Se crei degli indici nel tuo progetto iniziale, sottoponili a test posteriori. Potrebbero essere più problemi di quanti ne valga.)

Should I just skip creating indexes before it's needed because performance issues will show up anyway and probably the indexes that's already been created aren't being used?

No, se è chiaro che dovrai indicizzare alcune colonne. Se pianifichi una funzione che ricerca frequentemente offerte azionarie superiori o inferiori a un determinato prezzo, probabilmente vorrai un indice sul valore dell'offerta oltre alla chiave univoca del record.

Sì, se non è chiaro che l'indice garantirà al sistema generale un miglioramento delle prestazioni. L'unica query al mese per le offerte fatte per stato probabilmente non ha bisogno di un indice specifico.

Should indexes be treated as part of requirement/specification?

No . Gli indici sono un componente del design del software. Non hanno più spazio nei requisiti o nelle specifiche rispetto all'utilizzo di un particolare metodo di framework o nome di una variabile transitoria.

(È possibile che tutta o parte della programmazione provenga dal tuo cliente, ma è sciocco fare uso di tale requisito. Un server di indici non ha scopo se il server sta per mandare comunque l'intera tabella.)

La creazione di indici è un dettaglio dell'implementazione , non li considererei parte di una specifica. Il design della struttura del database di solito coinvolge solo la tabella & nomi di colonne e tipi di dati, non il DDL che verrà utilizzato per crearlo - ed è qui che verrebbe incluso CREATE INDEX .

Per le relazioni con le tabelle più complicate, non avrai indici su tutte le possibili combinazioni di chiavi in quanto non ha senso w.r.t. la logica del business. Tu dovresti crearli all'inizio su tutte le chiavi e amp; JOIN s, e imho usa semplicemente Explain Plan per catturare i casi limite.

Sì, la creazione di indici di database fa parte del design, dell'implementazione e dell'ottimizzazione.

• Un grande insieme di indici fa parte del design. La chiave primaria e gli indici di chiavi esterne rientrano in questa categoria. Le chiavi primarie e uniche sono costose da applicare senza un indice. Se capisci bene il design, puoi omettere alcuni indici di chiavi straniere. È inoltre possibile sostituire gli indici con colonne aggiuntive per l'indice di chiave esterna. Se i modelli di accesso sono ben compresi, è possibile specificare ulteriori indici. La chiave primaria e gli indici di chiavi esterne sono essenziali per unire prestazioni e ottimizzazione delle query. Il design specificherà le chiavi e gli indici che vengono creati durante l'implementazione.
• Durante l'implementazione creerai gli indici risultanti dal design. Il modello logico dal design può essere modificato. Ciò potrebbe comportare nuovi indici. Generalmente, l'implementazione dovrebbe comportare pochi nuovi indici.
• I problemi di prestazioni possono scoprire percorsi di accesso per i quali non è disponibile un indice appropriato. Una progettazione o implementazione più completa potrebbe aver scoperto alcuni di questi casi. In altri casi, l'uso effettivo o la distribuzione dei dati possono differire da quanto previsto durante la progettazione e l'implementazione. La distribuzione del valore di scala e dell'indice può avere un impatto significativo sul valore di un indice su una query e sul piano di query ottimizzato.

L'aggiunta di tutti gli indici di query che potrebbero essere, o dovrebbero essere, necessari al momento della progettazione o dell'implementazione sarebbe eccessiva. Ogni indice porta un overhead e troppi indici possono essere costosi.

Alcuni motivi per cui un indice potrebbe non essere utile includono:

• Il percorso di accesso è usato raramente o mai;
• Query Optimizer può scegliere un percorso di accesso diverso; o
• Un indice parziale fornisce un set di record sufficientemente piccolo.