Grundlæggende er en indeksorganiseret tabel et indeks uden en tabel. Der er et tabelobjekt, som vi kan finde i USER_TABLES, men det er kun en reference til det underliggende indeks. Indeksstrukturen matcher tabellens projektion. Så hvis du har en tabel, hvis kolonner består af den primære nøgle og højst én anden kolonne, så har du en mulig kandidat til INDEX ORGANIZED.
Den primære brugssituation for indeksorganiseret tabel er en tabel, som næsten altid er tilgået af dens primære nøgle, og vi ønsker altid at hente alle dens kolonner. I praksis er indeksorganiserede tabeller mest tilbøjelige til at være referencedata, kodeopslagsanliggender. Ansøgningstabeller er næsten altid hobe organiseret.
Syntaksen tillader en IOT at have mere end én ikke-nøglekolonne. Nogle gange er dette korrekt. Men det er også en indikation af, at vi måske skal genoverveje vores designbeslutninger. Hvis vi finder os selv at overveje behovet for yderligere indekser på de ikke-primære nøglekolonner, så er vi nok bedre stillet med en almindelig heap-tabel. Så da de fleste tabeller sandsynligvis har brug for yderligere indekser, er de fleste tabeller ikke egnede til IOT'er.
Når jeg vender tilbage til dette svar, ser jeg et par andre svar i denne tråd, der foreslår skæringstabeller som egnede kandidater til IOT'er. Dette virker rimeligt, fordi det er almindeligt, at skæringstabeller har en projektion, der matcher kandidatnøglen:STUDENTS_CLASSES kunne have en projektion på kun (STUDENT_ID, CLASS_ID).
Jeg tror ikke, det her er støbejern. Skæringstabeller har ofte en teknisk nøgle (dvs. STUDENT_CLASS_ID). De kan også have ikke-nøglekolonner (metadatakolonner som START_DATE, END_DATE er almindelige). Der er heller ingen fremherskende adgangsvej - vi ønsker at finde alle de elever, der tager en klasse lige så ofte, som vi ønsker at finde alle de klasser, en elev tager - så vi har brug for en indekseringsstrategi, som understøtter begge lige godt. Siger ikke skæringstabeller er ikke en use case for IOT'er. bare at de ikke automatisk er det.