Fondamentalement, une table organisée en index est un index sans table. Il y a un objet table que nous pouvons trouver dans USER_TABLES mais c'est juste une référence à l'index sous-jacent. La structure de l'index correspond à la projection du tableau. Donc, si vous avez une table dont les colonnes sont constituées de la clé primaire et d'au plus une autre colonne, vous avez un candidat possible pour INDEX ORGANIZED.
Le principal cas d'utilisation d'une table organisée en index est une table à laquelle on accède presque toujours par sa clé primaire et nous voulons toujours récupérer toutes ses colonnes. En pratique, les tables organisées en index sont plus susceptibles d'être des données de référence, des affaires de recherche de code. Les tables d'application sont presque toujours organisées en tas.
La syntaxe permet à un IOT d'avoir plus d'une colonne non clé. Parfois c'est correct. Mais c'est aussi une indication que nous devons peut-être reconsidérer nos décisions de conception. Certes, si nous nous retrouvons à envisager le besoin d'index supplémentaires sur les colonnes de clé non primaires, nous serions probablement mieux avec une table de tas régulière. Ainsi, comme la plupart des tables ont probablement besoin d'index supplémentaires, la plupart des tables ne conviennent pas aux IOT.
Pour en revenir à cette réponse, je vois quelques autres réponses dans ce fil proposer des tables d'intersection comme candidats appropriés pour les IOT. Cela semble raisonnable, car il est courant que les tables de croisement aient une projection qui correspond à la clé candidate :STUDENTS_CLASSES pourrait avoir une projection de seulement (STUDENT_ID, CLASS_ID).
Je ne pense pas que ce soit de la fonte. Les tables d'intersection ont souvent une clé technique (c'est-à-dire STUDENT_CLASS_ID). Ils peuvent également avoir des colonnes non clés (les colonnes de métadonnées telles que START_DATE, END_DATE sont courantes). De plus, il n'y a pas de chemin d'accès dominant - nous voulons trouver tous les étudiants qui suivent un cours aussi souvent que nous voulons trouver tous les cours qu'un étudiant suit - nous avons donc besoin d'une stratégie d'indexation qui prend en charge les deux aussi bien. Je ne dis pas que les tables d'intersection ne sont pas un cas d'utilisation pour les IOT. juste qu'ils ne le sont pas automatiquement.
