Indici Tabella - Giusta Implementazione?

di
Anonimizzato13935
il
8 risposte

Indici Tabella - Giusta Implementazione?

Buongiorno,
ho un dubbio riguardo la giusta implementazione degli indici in una tabella.

Immaginiamo due scenari differenti di strutturazione tabella:

Scenario1:
Tabella1 (ho omesso la chiave primaria... non è c'entra con l'esempio)
IDchiaveesterna (dalla parte molti di una relazione) -> numerico; Indicizzato: Sì (Duplicati ammessi ... perchè è nella parte "molti" della relazione)-
Campo1 -> Testo; Indicizzato: Sì (Duplicati non ammessi)-
una tabella del genere avrebbe 2 indici (uno x ogni campo)

Scenario2:
Tabella1 (ho omesso la chiave primaria... non è c'entra con l'esempio)
IDchiaveesterna (dalla parte molti di una relazione)-> numerico;
Campo1 -> Testo;
Unico indice composito da entrambi i campi con duplicati non ammessi...

considerato che il campo numerico è usato in molte query (se ne consiglia dunque l'indicizzazione), quale dei due scenari riferiti alla medesima tabella con molti record (più di 10000) è quello più performante?

Grazie

8 Risposte

  • Re: Indici Tabella - Giusta Implementazione?

    Trovo la domanda alquanto curiosa...voglio risponderti secondo miei casi concreti. Lo Scenario 2 mi sembra più realistico: io l'ho applicato spesso, se non altro perchè era quella l'esigenza. Comunque nessuno ti vieta nello Scenario 2 di avere sia un Indice Multicampo Univoco su Campo1 e CampoIDNumerico, sia un altro Indice non univoco su CampoIDNumerico.
    Se devo essere sincero sincero, metto in gioco la mia ignoranza in matera, non ho mai colto/capito la differenza fra:
    Indicizzato: No
    Indicizzato: Sì (Duplicati ammessi).
    Se in una query imposti Ordinamento Crescente su tale campo, la query lavora nella stessa maniera.
  • Re: Indici Tabella - Giusta Implementazione?

    OsvaldoLaviosa ha scritto:


    Comunque nessuno ti vieta nello Scenario 2 di avere sia un Indice Multicampo Univoco su Campo1 e CampoIDNumerico, sia un altro Indice non univoco su CampoIDNumerico.
    In effetti non avevo considerato che potevo impostarli entrambi

    OsvaldoLaviosa ha scritto:


    Se devo essere sincero sincero, metto in gioco la mia ignoranza in matera, non ho mai colto/capito la differenza fra:
    Indicizzato: No
    Indicizzato: Sì (Duplicati ammessi).
    Se in una query imposti Ordinamento Crescente su tale campo, la query lavora nella stessa maniera.
    in realtà una query dove si effettua una ricerca su un campo indicizzato è più veloce della stessa query che effettua la medesima ricerca su un campo non indicizzato... quando scrivo "effettua una ricerca su un campo" intendo dire che nella riga "criteri" deve esserci un paramentro...

    documentandomi meglio ho letto che l'indice da impostare è quello che più raffigura la "situazione di ricerca"...
    se c'è una query che ricerca contemporaneamente su entrambi i campi converrà l'indice composito.. viceversa se la ricerca nei campi avviene in query diverse e mai contemporaneamente converrebbe indicizzarli separatamente....

    nel mio caso visto che avevo entrambe le situazioni non sapevo come impostare... credo che adotterò il suggerimento di Osvaldo
  • Re: Indici Tabella - Giusta Implementazione?

    La dove le query propagano SELECT o JOIN è utile che i campi siano indicizzati se la ricerfca viene effettuata sul campo specifico, altrimenti vale l'AutoLookup dei dati...

    Scenario 1 è indubbiamente quello da prendere in considerazione in tutti i casi, le FK a mio giudizio dovrebbero sempre essere INDICI.
  • Re: Indici Tabella - Giusta Implementazione?

    Grazie della risposta Alex,

    quindi se non ho interpretato male:
    1) Conviene SEMPRE evitare gli indici compositi a vantaggio di quelli singoli (scenario1)
    2) Gli indici vanno usati solo nei casi in cui i campi cui essi si riferiscono sono usati come punto estremo nelle relazioni tra tabelle/query... negli altri casi c'è la funzione integrata di autolookup

    ... scusami l'ignoranza... FK? presumo K per key... ma F?

    a presto
  • Re: Indici Tabella - Giusta Implementazione?

    OsvaldoLaviosa ha scritto:


    Trovo la domanda alquanto curiosa...voglio risponderti secondo miei casi concreti. Lo Scenario 2 mi sembra più realistico: io l'ho applicato spesso, se non altro perchè era quella l'esigenza. Comunque nessuno ti vieta nello Scenario 2 di avere sia un Indice Multicampo Univoco su Campo1 e CampoIDNumerico, sia un altro Indice non univoco su CampoIDNumerico.
    Se devo essere sincero sincero, metto in gioco la mia ignoranza in matera, non ho mai colto/capito la differenza fra:
    Indicizzato: No
    Indicizzato: Sì (Duplicati ammessi).
    Se in una query imposti Ordinamento Crescente su tale campo, la query lavora nella stessa maniera.
    Magari può essere utile capire che l'uso di un indice ha degli enormi vantaggi, mentre l'ordinamento in sé non ha nulla a che vedere.
    Vero è che l'ordinamento sarà molto più veloce su un campo indicizzato che non.

    Leggi questo post e capirai la differenza tra campi indicizzati e non:

    http://www.visual-basic.it/Forum/tabid/151/aft/41380/Default.aspx#.U0_GOxiao3x
  • Re: Indici Tabella - Giusta Implementazione?

    Angelo_Tbp ha scritto:


    Grazie della risposta Alex,

    quindi se non ho interpretato male:
    1) Conviene SEMPRE evitare gli indici compositi a vantaggio di quelli singoli (scenario1)
    2) Gli indici vanno usati solo nei casi in cui i campi cui essi si riferiscono sono usati come punto estremo nelle relazioni tra tabelle/query... negli altri casi c'è la funzione integrata di autolookup

    ... scusami l'ignoranza... FK? presumo K per key... ma F?

    a presto
    FK = FOREIGN KEY
    ovvero chiave esterna.

    http://www.w3schools.com/sql/sql_foreignkey.as
  • Re: Indici Tabella - Giusta Implementazione?

    Gli indici composti sono solo più difficili o scomodi da gestire in realtà non ci vedo altre controindicazioni...

    L'uso degli indici in generale è consigliato per l'ottimizzatore del motore del DB... in sostanza qualsiasi azione di ricerca su campi viene ottimizzata se questi sono indicizzati.
    Perchè non indicizzarli tutti...?
    Ci sono 2 motivi...
    1) Perchè ci sono LIMITI FISICI di ogni DB che supporta un Numero Massimo di INCIDI, per Access o meglio per JET(riferito ad A2003 ma fino a A2010 è uguale) è 32, come puoi vedere quì:
    http://office.microsoft.com/it-it/access-help/specifiche-di-access-HP005186808.aspx
    oppure quì:
    http://office.microsoft.com/it-it/access-help/specifiche-di-access-2010-HA010341462.aspx
    2) Perchè in tutti i casi l'uso di INDICI crea una sorta di Archivio o di Tabelle parallele degli Indici, aumentando pertanto le dimensioni del DB ed appesantendo la fase di INSERIMENTO(è pur vero che in questa fase della lentezza non frega nulla a nessuno essendo spesso per SINGOLO RECORD).
    Il concetto di INDICE nasce dalle vecchie teorie di ottimizzazione dei File Testo...
    In sostanza vedi una Rubrica Telefonica... per velocizzare la ricerca, oltre ad avere gli Iscritti ordinati per Cognome, hanno inserito la LETTERA INIZIALE marcata sul BORDO PAGINA che ti consente di INDICIZZARE per LETTERA la ricerca, cosicchè tu punti a B per Bianchi senza sfogliare tutto...

    Puoi leggere qualche leggerezza quì:

    http://office.microsoft.com/it-it/access-help/creare-e-utilizzare-un-indice-per-migliorare-le-prestazioni-HA010210347.aspx

    Molti DBManager hanno a supporto anche un'analizzatore di Performances, che analizzando la struttura suggerisce se eventualmente è bene che alcuni campi vengano ridefiniti INDICI... se non ricordo male anche Access ha una cosa simile..., almeno fino alla versione 2003...

    PK=Primary Key(Chiave Primaria)
    FK=Foreign Key(Chiave Esterna, lato Molti...)

    P.S. mi sono sovrapposto a Gibra...
  • Re: Indici Tabella - Giusta Implementazione?

    Grazie 1000 siete stati davvero molto illuminanti

    nell'ultimo post di Alex ho trovato conferma di ciò che mi affliggeva attraverso la lettura del paragrafo "Indici multicampo" che cito:
Devi accedere o registrarti per scrivere nel forum
8 risposte