Bonjour,
j'ai une petite question sur l'option organization index lors de la creation d'une table:
Cette option equivaut à créer un index sur chaque champs qui compose la PK?
Oui?
Non?
Merci
Version imprimable
Bonjour,
j'ai une petite question sur l'option organization index lors de la creation d'une table:
Cette option equivaut à créer un index sur chaque champs qui compose la PK?
Oui?
Non?
Merci
Bonjour ,
Non cela équivaut à avoir un index , sur toutes les colonnes de la tables .
Sauf que dans ce cas la on fait l'économie de l'espace :wink:
Pour être clair, cela permet de constituer une table qui a la même structure qu'un index B-Tree.
Pour simplifier, on va dire que toutes les colonnes de la table sont intégrées dans l'index et que la lecture de celui-ci suffit à ramener les infos.
Bonjour,
Pas du tout ! Une telle table est "organisée en index" : elle a une PK, et les données sont dans les feuilles du B*Tree de l'index de
cette PK.
Tu peux ensuite créer d'autres indexes (dit secondaires) sur cette table.
Laly.
Bonjour,
Je ne suis pas d'accord : ce qui est indexé, c'est uniquement la PK de cette table.Citation:
Envoyé par jaouad
Laly.
Comme ca c'est bcp plus explicite :
Citation:
Une IOT est une table standart avec un idex concaténé sur toutes les colonnes .Cependant , contrairement à l'utilsation de deux segments distincts pour la table et l'index b-tree , le serveur Oracle gère une structure B-tree contenant :
Les valeurs de clé primaires
Les valeurs des autres colonnes ( non-clé) de la ligne
La structure b-tree , basé sur la clé primaire de la table est organisé comme un index .Les blocs feuille de cette structure contiennent des lignes à la place des ROWID .
AUtrement dit les lignes de la IOT sont toujours gérées selon l'ordre de la clé primaire .
Vous pouvez créer des Index supplémentaires sur les IOT .Etant donnée que les lignes volumineuses d'une IOT peuvent réduirte à néant l'efficacité et la densité du stockage d'une stucture b-tree .Vous pouvez stocker une partie de la ligne dans un autre segment appellé zone de débordement .
effectivement ce que je voualis dire c'était qu'IOT gére toutes les colonnes ( même ne faisant pas partie de la PK ) sauf si on spécifie la zone de débordementCitation:
Envoyé par lalystar
au fait, si je ne me trompe pas, une IOT est une table organisée en index, cad, que c'est comme si on avait un index B-tree sur la clé primaire d'une table, mais que la ligne de chaque index contient, le rowid, la valeur de la clé primaire et aussi le reste des valeurs de colones de la ligne, et tout ça dans un même segment. autrement dit j'ai toute ma table et toutes ses données dans une organisation b-tree comme un index.
juste une question, pourquoi avoir le rowid de la ligne dans ce cas, là !!, ou est ce que je me trompe?, on ne l'a ptet pas !!!?, il ne reste plus rien de l'index dans ce cas :roll: , c que du B-tree pour faciliter la recherche de la clé :? !!.....ou est ce que je me trompe :oops:
Justement, une IOT n'a pas besoin de ROWID puisque toutes les données sont dans l'index !
donc il n'y a pas de ROWID dans une IOT.
En fait dans une IOT il y a un rowid logique, qui est la clé primaire. La position d'une ligne dépend uniquement de la clé primaire.
Mais les indexes secondaires utilisent un rowid classique; sinon ils ne seraient pas performant du tout.
Si on a une IOT de profondeur 3 par exemple et un index secondaire de profondeur 3, alors l'accès à une ligne de l'IOT par un index couterait 6 I/O.
Quand on tente d'accéder à une ligne d'une IOT via un index secondaire, Oracle va chercher dans le bloc dont l'adresse est indiqué dans l'index secondaire, si la valeur cherchée y figure ou pas (en effet la position d'une ligne dans une IOT peut changer : si il y a réquilibrage du B*Tree par ex). Si la valeur y figure bien c'est gagné, ca nous à couté avec notre exemple 3 I/O pour la recherche dans l'index secondaire + 1 I/O supplémentaire pour l'accès à la ligne via le rowid.
Si la valeur n'y figure pas, on utilise alors la valeur de la PK de la ligne recherchée qui est aussi stockée dans l'index secondaire. Dans ce cas ca nous aura couté 3 I/O (lecture de l'index) + 1 I/O (accès via le rowid physique -> échec) + 3 I/O (accès via la PK).
Laly.
Une IOT étant sensé stocker dans l'index toutes les colonnes (et donc celles de la PK) un index secondaire n'a que peu d'interêt...
Pas d'accord, une IOT est une table à la base. Elle est stockée sous forme d'un B*Tree soit. Les indexes secondaires sont les équivalents des indexes sur une table normale.Citation:
Envoyé par SheikYerbouti
Si on a une table COTATION(id, date, cotation), dont la PK est (id, date) (on a une quote par société par jour), il est intéressant de la stocker sous la forme d'une IOT car :
- les données d'un même id seront physiquement proches (intéressant pour des calculs de moyennes par id par ex.)
- on économise l'espace de la PK
Mais si j'ai besoin de connaitre toutes les cotations pour une date donnée, je vais placer un index secondaire sur la colonne date.
Laly.
Inutile depuis la 9i puisque l'index sera utilisé même si la requête n'utilise pas toutes les colonnes de l'index. (date dans ton exemple)
Si tu parles du skip scan index, un index multi-colonne peut effectivement être utilisé si la première colonne est de cardinalité faible... ce qui n'est pas le cas dans mon exemple, quand on gère des cotations de plusieurs milliers de sociétés...
Laly.