Discussion :

[ouadie99]

Bonjour,

on sait déja que les index permet d'effectuer plus rapidement des recherches.
donc ici pour les requetes de type select

mais si des requetes d'insertion, modification et suppression est ce que c la meme chose?

par exemple j'ai une table qui contient un champ nom comme colonne j'ai crée un index pour ce champ dans la requete de seletion c'est bien parfait

mais lorsque j'ai effectué une requete de suppression est ce que index sera supprimé également ou bien il y a autre action pour l'update et insert ?

si vous avez des réponses n'hésitez pas de m'aider.

[orafrance]

Imagine toi le Quid. Quelques milliers de pages et donc un index pour s'y retrouver. Pour trouver un article c'est très efficace puisqu'il suffit de parcourir 10 pages d'index rangé par ordre alphabétique plutôt que des milliers de pages sans ordre particulier. Par contre, si un article est ajouté, supprimé ou déplacé, non seulement il y a la modification de l'article à faire mais aussi l'index à mettre à jour pour changer le numéro de page ou de colonne dans la page.

Pour Oracle c'est pareil

[ouadie99]

d'abord merci ,mais j'ai lu une documentation en anglais sur les indexes sur oracle
dans la rubrique les avantages et les inconvénients il décrit que parmi les inconvénients
Ne pas créer un index lorsque The table is updated frequently est ce que tu me confirme dans ce sens?

[Vincent Rogier]

Ne pas créer un index lorsque The table is updated frequently

C'est un conseil stupide ! Cela dépend bien sur du contexte... Mais un index a pour but d'optimiser les recherches.

Donc si la table est mise à jour fréquemment mais aussi consultée fréquemment avec des critères, un index s'imposera si elle gagne en volume.. De plus cela dépend aussi de la nature des données et leur répartition....

[13thFloor]

Que préfères-tu ?
perdre un chouia de seconde lors d'une mise à jour mais booster les lectures
ou accélérer les mises à jour mais ne pas booster les lectures et se taper des full table scan ?
Dans beaucoup d'ERP, il arrive de voir des tables avec 5, 10 voire plus de 15 index.

[agdid04]

Que préfères-tu ?
perdre un chouia de seconde lors d'une mise à jour mais booster les lectures
ou accélérer les mises à jour mais ne pas booster les lectures et se taper des full table scan ?
Dans beaucoup d'ERP, il arrive de voir des tables avec 5, 10 voire plus de 15 index.

Bonsoir,
En cas de chargemnts massifs: drop index, chargement puis create index ...
Crdlt,
SDR

[ouadie99]

C'est un conseil stupide ! Cela dépend bien sur du contexte... Mais un index a pour but d'optimiser les recherches.

Donc si la table est mise à jour fréquemment mais aussi consultée fréquemment avec des critères, un index s'imposera si elle gagne en volume.. De plus cela dépend aussi de la nature des données et leur répartition....

Merci monsieur vicenzo pour la réponse cité au dessus mais ici lorsque j'ai une requete de select et update et delete ce ne pose pas probléme au niveau des indexe car on utilise la clause where.

mais on sait déja que la requete de type insert n'utilise pas la clause where
donc est ce que c la meme chose c à d optimal ou bien ca pose un probléme

[Vincent Rogier]

g pa kmpri la ktion .....




Traduction : Je n'ai pas compris ton dernier post...

[orafrance]

Ne pas créer un index lorsque The table is updated frequently est ce que tu me confirme dans ce sens?

comme je l'ai dis, un update met l'index à jour, c'est donc couteux. Ceci étant dit, l'index peut servir aussi à accélérer l'exécution de l'update, exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
UPDATE tab
col = 'toto'
WHERE col = 'titi'

S'il y a un index sur col, tu as des chances que l'aide qu'il apporte pour trouver la ligne compense la perte de temps lors de la mise à jour de l'index... et on peut en plus espérer que tu sélectionnes plus souvent que tu updates

Donc je ne confirme pas

PS : t'as un lien sur la source qui dit ça ?