V podstatě indexově organizovaná tabulka je index bez tabulky. Existuje objekt tabulky, který můžeme najít v USER_TABLES, ale je to pouze odkaz na základní index. Struktura indexu odpovídá projekci tabulky. Pokud tedy máte tabulku, jejíž sloupce se skládají z primárního klíče a nejvýše jednoho dalšího sloupce, pak máte možného kandidáta na INDEX ORGANIZED.
Hlavním případem použití indexově organizované tabulky je tabulka, ke které se téměř vždy přistupuje pomocí jejího primárního klíče a vždy chceme získat všechny její sloupce. V praxi jsou indexově organizované tabulky s největší pravděpodobností referenčními daty, záležitostmi vyhledávání kódu. Tabulky aplikací jsou téměř vždy uspořádány na hromadě.
Syntaxe umožňuje IOT mít více než jeden neklíčový sloupec. Někdy je to správné. Ale je to také znamení, že možná budeme muset přehodnotit svá rozhodnutí o designu. Pokud se přistihneme, že uvažujeme o potřebě dalších indexů ve sloupcích s neprimárním klíčem, pak by nám pravděpodobně lépe vyhovovala běžná tabulka haldy. Protože většina tabulek pravděpodobně potřebuje další indexy, většina tabulek není vhodná pro IOT.
Když se vrátím k této odpovědi, vidím v tomto vlákně několik dalších odpovědí, které navrhují průsečíkové tabulky jako vhodné kandidáty pro IOT. Zdá se to rozumné, protože u průsečíkových tabulek je běžné, že mají projekci, která odpovídá kandidátskému klíči:STUDENTS_CLASSES může mít projekci právě (STUDENT_ID, CLASS_ID).
Nemyslím si, že je to litina. Průsečíkové tabulky mají často technický klíč (tj. STUDENT_CLASS_ID). Mohou mít také neklíčové sloupce (běžné jsou sloupce metadat jako START_DATE, END_DATE). Také neexistuje žádná převládající přístupová cesta – chceme najít všechny studenty, kteří navštěvují třídu, stejně často, jako chceme najít všechny třídy, které student navštěvuje – takže potřebujeme strategii indexování, která podporuje obojí stejně dobře. Neříkám, že průsečíkové tabulky nejsou případem použití pro IOT. jen to, že nejsou automaticky.