I grund och botten är en indexorganiserad tabell ett index utan en tabell. Det finns ett tabellobjekt som vi kan hitta i USER_TABLES men det är bara en referens till det underliggande indexet. Indexstrukturen matchar tabellens projektion. Så om du har en tabell vars kolumner består av primärnyckeln och högst en annan kolumn så har du en möjlig kandidat för INDEX ORGANIZED.
Det huvudsakliga användningsfallet för indexorganiserad tabell är en tabell som nästan alltid nås av sin primärnyckel och vi vill alltid hämta alla dess kolumner. I praktiken är indexorganiserade tabeller mest sannolikt referensdata, koduppslagsaffärer. Applikationstabeller är nästan alltid högorganiserade.
Syntaxen tillåter en IOT att ha mer än en icke-nyckelkolumn. Ibland stämmer detta. Men det är också en indikation på att vi kanske behöver ompröva våra designbeslut. Visst om vi finner oss själva överväga behovet av ytterligare index på de icke-primära nyckelkolumnerna så är vi förmodligen bättre med en vanlig heaptabell. Så eftersom de flesta tabeller förmodligen behöver ytterligare index är de flesta tabeller inte lämpliga för IOTs.
När jag kommer tillbaka till det här svaret ser jag att ett par andra svar i den här tråden föreslår skärningstabeller som lämpliga kandidater för IOT. Detta verkar rimligt, eftersom det är vanligt att skärningstabeller har en projektion som matchar kandidatnyckeln:STUDENTS_CLASSES kan ha en projektion på bara (STUDENT_ID, CLASS_ID).
Jag tror inte att det här är gjutjärn. Skärningstabeller har ofta en teknisk nyckel (dvs STUDENT_CLASS_ID). De kan också ha icke-nyckelkolumner (metadatakolumner som START_DATE, END_DATE är vanliga). Det finns heller ingen rådande åtkomstväg - vi vill hitta alla elever som går en klass lika ofta som vi vill hitta alla klasser en elev går - så vi behöver en indexeringsstrategi som stödjer båda lika bra. Jag säger inte att skärningstabeller inte är ett användningsfall för IOT:er. bara att de inte är det automatiskt.