Indicizzazione di un database

Non ho molta familiarità con i database e ora sto cercando di capire il meccanismo di indicizzazione.

Da quello che so, in un RDBMS, l'indicizzazione su una colonna rende più veloce la ricerca per quella colonna. Questo vale anche per i negozi tripli, solo lì gli indici presuppongono che si cercherà (ad esempio) principalmente per soggetto, quindi per oggetto e così via.

Non sono sicuro di RDBMS, ma sui negozi tripli puoi definire più di un indice, lasciando che il negozio scelga l'indice migliore per ogni query (speriamo di aver capito bene). Naturalmente, appare la seguente domanda:

Perché non dovrei aggiungere tutti i possibili indici a un triplo archivio e estenderli a un RDBMS, perché non creare indici su ogni colonna (supponendo che non sia troppo pigro)?

Perché, in sostanza, un indice è una tabella aggiuntiva, in cui la chiave primaria è il campo che stai indicizzando e l'unico contenuto è la chiave primaria della tabella principale. Quindi ogni aggiornamento deve essere replicato in ogni indice che utilizza il campo che aggiorni.

Ciò è particolarmente evidente sugli inserti. Immagina se ogni inserto che hai fatto su una tabella dovesse essere replicato su altre 20 tabelle. Sarà dolorosamente lento.

Nota che questo peggiora ancora con gli indici composti, raggruppati e full-text, ma non voglio ancora complicarti il ​​problema.

Gli indici sono sostanzialmente strutture dati aggiuntive che devono essere costruite e archiviate. La costruzione di energia di CPU indebolita (durante le operazioni di scrittura) e la sua memorizzazione fa perdere capacità del disco.

Perché dovresti creare e archiviare indici che non usi mai?

Posizionare gli indici solo quando necessario. Come regola generale quando sto sviluppando uno schema di database, ogni tabella ottiene un indice cluster chiave primaria PK per iniziare. Questo sarà l'identificatore univoco per i dati in quella tabella. In può essere su 1 colonna o più.

Successivamente, di solito aggiungo solo gli indici univoci non cluster sulle colonne sulle quali desidero applicare l'univocità.

Questo è lo schema di base. Man mano che l'applicazione viene sviluppata e matura, aggiungiamo indici in base alle esigenze in base alle preoccupazioni relative alle prestazioni e al modo in cui eseguiamo la query dei dati.

Ogni indice aggiunto aumenta la spaziatura utilizzata e l'aggiunta di ulteriore manutenzione. Quindi scegli i tuoi indici con saggezza.

Il punto di forza degli indici è che sono 1) una struttura di dati che può essere rapidamente cercata e 2) più compatta delle tabelle effettive, consentendo a più indice di adattarsi alla memoria anziché essere impaginato sul disco.

Se hai un indice su ogni colonna, gli indici stessi occuperanno più spazio della tabella che rappresentano. Se il database utilizza davvero tutti gli indici, richiederà più tempo solo per scambiarli dentro e fuori dalla memoria. Inoltre, ogni indice deve essere aggiornato su un inerte, aggiornamento o eliminazione.

Oltre a ciò, gli indici su una singola colonna non sono nemmeno il meglio che puoi fare. La maggior parte dei database delle relazioni in realtà consente un indice su più colonne e l'ordine di queste colonne è importante. Ad esempio, se voglio cercare in un database tutte le persone che sono andate a Duke dalle classi tra il 1980 e il 1984, allora quello che voglio è un indice su (Scuola, ClassYear). La query non sarebbe in grado di utilizzare un indice con le stesse colonne, ma al contrario.

Quindi, per creare ogni possibile indice, ci sono almeno n! modi per disporre le colonne in un indice. Con solo 5 colonne, ci sono 120 possibili indici.

Dato che ci sono così tanti indici possibili, devi davvero determinare quali indici sono utili per la tua applicazione e creare solo quelli.

La creazione di un indice per ogni colonna in una tabella di solito è uno spreco di spazio e, come altri hanno già detto, può rallentare le operazioni di inserimento / aggiornamento. Un indice viene utilizzato per accelerare le query. Ti consiglio di aggiungere un indice a una colonna solo se noti prestazioni scadenti quando esegui una query per i valori in quella colonna.

Alcuni database potrebbero richiedere un indice per la chiave primaria di una tabella, quindi potresti non avere scelta su quella. Inoltre, se hai colonne di testo molto grandi, ci sono tecnologie specifiche progettate per la ricerca e l'indice full-text, ma non sono sempre gli stessi tipi di indice che utilizzeresti per una piccola colonna numerica.