Discussion :

[stof]

Créons maintenant un index B-tree (très important B-tree) (..)

C'est un index classique B-tree non ?

Mais s'il y a un autre utilisateur qui veut ajouter un enregistrement fils, mais qui n'a pas encore terminé sa transaction, alors on ne le verra pas. Et lui ne verra pas notre delete en cours non plus ...

Ma base est en mode Row Lock; est-ce que cette explication sur l'utilité des index sur les FK du coup ne me concerne plus du tout?

[pachot]

Ma base est en mode Row Lock; est-ce que cette explication sur l'utilité des index sur les FK du coup ne me concerne plus du tout?

Oracle fait toujours des verrous lignes. Ce n'est pas le problème ici.
Il faut poser un verrou pour empêcher des modifications concurrentes incompatible et c'est l'index sur la FK qui offre la structure qui évite de vérouiller toute la table.

[pachot]

Je réponds brièvement...désolé:

1°/

Oui, exact.

2°/

pour le trunc, aulieu de trunc(DATE)=x faire date>=x and date<x+1
{A, DATE} et C probablement inutiles pour ce besoin, oui, car {A, DATE, C, D, E} peut être utilisé aussi.


3°/

L'accès via des index distincts sera beaucoup beaucoup moins optimal qu'un index {B, C, D, E}
Sauf dans le cas d'index bitmap... mais c'est une autre histoire.

4°/

#12 oui, contrainte et index. Mais l'index implicite est souvent le bon.

#13 oui index utile pour selectionner peu de données. Mais sans prédicats, mieux vaut un full scan.