Basicamente, uma tabela organizada por índice é um índice sem uma tabela. Existe um objeto de tabela que podemos encontrar em USER_TABLES, mas é apenas uma referência ao índice subjacente. A estrutura do índice corresponde à projeção da tabela. Portanto, se você tiver uma tabela cujas colunas consistem na chave primária e no máximo uma outra coluna, você terá um possível candidato a INDEX ORGANIZED.

O principal caso de uso para tabela organizada por índice é uma tabela que quase sempre é acessada por sua chave primária e sempre queremos recuperar todas as suas colunas. Na prática, as tabelas organizadas por índice são mais provavelmente dados de referência, assuntos de pesquisa de código. As tabelas de aplicativos são quase sempre organizadas em pilha.

A sintaxe permite que um IOT tenha mais de uma coluna não chave. Às vezes isso está correto. Mas também é uma indicação de que talvez precisemos reconsiderar nossas decisões de design. Certamente, se nos encontrarmos contemplando a necessidade de índices adicionais nas colunas de chave não primária, provavelmente estaremos melhor com uma tabela de heap regular. Portanto, como a maioria das tabelas provavelmente precisa de índices adicionais, a maioria das tabelas não é adequada para IOTs.

Voltando a esta resposta, vejo algumas outras respostas neste tópico que propõem tabelas de interseção como candidatas adequadas para IOTs. Isso parece razoável, porque é comum que as tabelas de interseção tenham uma projeção que corresponda à chave candidata:STUDENTS_CLASSES poderia ter uma projeção de apenas (STUDENT_ID, CLASS_ID).

Eu não acho que isso é ferro fundido. As tabelas de interseção geralmente têm uma chave técnica (ou seja, STUDENT_CLASS_ID). Eles também podem ter colunas não chave (colunas de metadados como START_DATE, END_DATE são comuns). Além disso, não há um caminho de acesso predominante - queremos encontrar todos os alunos que frequentam uma aula com a mesma frequência que queremos encontrar todas as aulas que um aluno está fazendo - portanto, precisamos de uma estratégia de indexação que suporte ambos igualmente bem. Não estou dizendo que as tabelas de interseção não são um caso de uso para IOTs. apenas que eles não são automaticamente assim.